K8S儲存之PV和PVC

阿新 • • 發佈：2020-12-17

1 介紹

對於管理計算資源來說，管理儲存資源明顯是另一個問題。PersistentVolume子系統為使用者和管理員提供了一個API，該API將如何提供儲存點細節抽象了出來。為此，我們引入兩個新的API資源：PersistentVolume和PersistentVolumeClaim。

持久卷（PersistentVolume，PV）是由管理員設定的儲存，可以由管理員事先供應，或者使用儲存類（Storage Class）來動態供應。持久卷是叢集資源，就像節點也是叢集資源一樣。PV持久卷和普通的Volume一樣，也是使用卷外掛來實現的，只是它們擁有獨立於任何使用PV的Pod的生命週期。此API物件中記述了儲存的實現細節，無論背後是NFS、iSCSI還是特定於雲平臺的儲存系統。

持久卷申領（PersistentVolumeClaim，PVC）表達的是使用者對儲存的請求。概念上與Pod類似。Pod會耗用節點資源，而PVC申領會耗用PV資源。Pod可以請求特點數量點資源（CPU和記憶體）；同樣PVC申領也可以請求特定大小和訪問模式（例如，可以要求PV卷能夠以ReadWriteOnce、ReadOnlyMany或ReadWriteMany模式之一來掛載）

儘管 PersistentVolumeClaim 允許使用者消耗抽象的儲存資源，常見的情況是針對不同的問題使用者需要的是具有不同屬性（如，效能）的 PersistentVolume 卷。叢集管理員需要能夠提供不同性質的 PersistentVolume，並且這些 PV 卷之間的差別不僅限於卷大小和訪問模式，同時又不能將卷是如何實現的這些細節暴露給使用者。為了滿足這類需求，就有了儲存類（StorageClass）資源。

2 卷和申領的生命週期

PV卷是叢集中的資源。PVC申領是對這些資源的請求，也被用來執行對資源的申領檢查。PV卷和PVC申領之間的互動遵循以下什麼週期：

2.1 配置（Provision）

PV卷的配置有兩種方式：靜態或動態

2.2 靜態

叢集管理員建立若干PV卷。這些卷物件帶有真實儲存的細節資訊，並且對叢集使用者可用（可用）。PV卷物件存在於Kubernetes API中，可供使用者消費（使用）。

2.3 動態

如果管理員所建立的所有靜態PV卷都無法與使用者的PersistentVolumeClaim匹配，叢集可以嘗試為該PVC申領動態供應一個儲存卷。這一供應操作是基於StorageClass來實現的；PVC申領必須請求某個儲存類，同時叢集管理員必須已經建立並配置了該類，這樣動態供應鏈的動作才會發生。如果PVC申領指定儲存類為“”，則相當於自身禁止使用動態供應的卷。

為了基於儲存類完成動態的儲存供應，叢集管理員需要在API伺服器上啟用DefaultStorageClass准入控制器。舉例而言，可以通過保證DefaultStorageClass出現在API伺服器元件的 --enable-admission-plugins標誌的值可以是逗號分隔的有序列表。

2.4 繫結

再動態配置的情況下，使用者建立或已經建立了具有特點儲存量的PersistentVolumeClaim以及某些訪問模式。master中的控制環路監視新的PVC，尋找匹配的PV（如果可能），並將它們繫結在一起。如果新的PVC動態調配PV，則該環路將始終把該PV繫結到PVC。否則，使用者總會得到他們所請求的儲存，但是容量可能超出要求的數量。一旦PV和PVC繫結後，PersistentVolumeClaim繫結是排他性的，不管它們是如何繫結的。PVC跟PV繫結是一對一的對映。

如果沒有匹配的卷，宣告將無限期地保持未繫結狀態。隨著匹配卷的可用，宣告將被繫結。例如，配置了許多50Gi PV的叢集將不會匹配請求100Gi的PVC。將100Gi PV新增到叢集是，可以繫結PVC。

2.5 使用

Pod使用宣告作為卷。叢集檢查宣告以查詢繫結的卷併為叢集掛載改卷。對於支援多種訪問模式的卷，使用者指定在使用宣告作為容器中的卷時所需的模式。

使用者進行了宣告，並且該宣告是繫結的，則只要使用者需要，繫結的PV就屬於該使用者。使用者通過在Pod的volume配置中包含persistentVolumeClaim來排程Pod並訪問使用者宣告的PV。

2.6 持久化卷宣告點保護

PVC保護的目的是確保由pod正在使用的PVC不會從系統中移除，因為如果被移除的話可能會導致資料丟失。

注意：當pod狀態為Pending並且pod已經分配給節點或pod為Running狀態時，PVC處於活動狀態。

當啟⽤PVC保護alpha功能時，如果⽤戶刪除了⼀個pod正在使⽤的PVC，則該PVC不會被⽴即刪除。PVC的刪除將被推遲，直到PVC不再被任何pod使⽤。

您可以看到，當PVC的狀態Teminatiing時，PVC受到保護，Finalizers列表中包含 kubernetes.io/pvc-protection：

kubectl described pvc hostpath
Name: hostpath
Namespace: default
StorageClass: example-hostpath
Status: Terminating
Volume:
Labels: <none>
Annotations: volume.beta.kubernetes.io/storage-class=example-hostpath
            volume.beta.kubernetes.io/storage-provisioner=example.com/hostpath
Finalizers: [kubernetes.io/pvc-protection]
...

2.7 回收

⽤戶⽤完volume後，可以從允許回收資源的API中刪除 PVC 物件。PersistentVolume的回收策略告訴叢集在儲存卷宣告釋放後應如何處理該卷。⽬前，volume的處理策略有保留、回收或刪除。

2.8 保留

保留回收策略允許⼿動回收資源。當PersistentVolumeClaim被刪除時， PersistentVolume仍然存在，volume被視為“已釋放”。但是由於前⼀個宣告⼈的資料仍然存在，所以還不能⻢上進⾏其他宣告。管理員可以通過以下步驟手動回收卷。

1、刪除PersistentVolume。在刪除PV後，外部基礎架構中的關聯儲存資產（如AWS EBS、GCE PD、Azure Disk或Cinder卷）仍然存在。

2、手動清理相關儲存資產上的資料。

3、⼿動刪除關聯的儲存資產，或者如果要重新使⽤相同的儲存資產，請使⽤儲存資產定義建立新的PersistentVolume。

2.9 回收

如果儲存卷外掛⽀持，回收策略會在volume上執⾏基本擦除（rm -rf /thevolume/*），可被再次宣告使⽤。

但是，管理員可以使⽤如此處所述的Kubernetes controller manager命令⾏引數來配置⾃定義回收站pod模板。⾃定義回收站pod模板必須包含volumes規範，如下⾯的示例所示：

apiVersion: v1
kind: Pod
metadata:
  name: pv-recycler
  namespace: default
spec:
  restartPolicy: Never
  volumes:
  - name: vol
    hostPath:
    path: /any/path/it/will/be/replaced
  containers:
  - name: pv-recycler
    image: "k8s.gcr.io/busybox"
    command: ["/bin/sh", "-c", "test -e /scrub && rm -rf /scrub/..?* /scrub/.[!.]* /scrub/* && test -z \"$(ls -A /scrub)\" || exit 1"]
    volumeMounts:
    - name: vol
      mountPath: /scrub

但是，volumes部分的⾃定義回收站模組中指定的特定路徑將被替換為正在回收的卷的特定路徑。

2.10 刪除

對於⽀持刪除回收策略的卷外掛，刪除操作將從Kubernetes中刪除 PersistentVolume 物件，並刪除外部基礎架構（如AWS EBS、GCE PD、Azure Disk或Cinder卷）中的關聯儲存資產。動態配置的卷繼承其 StorageClass ，預設為Delete。管理員應該根據⽤戶的期望來配置 StorageClass，否則就必須要在PV建立後進⾏編輯或修補。請參閱更改PersistentVolume 的回收策略。

#kubectl explain PersistentVolume

Capacity: #當前PV空間大小,kubectl explain PersistentVolume.spec.capacity

AccessModes: #訪問模式,
    ReadWriteOnce(RWO) -- the volume can be mounted as read-write by a single node -- #PV只能被單個節點以讀寫許可權掛載
    ReadOnlyMany(ROX) -- the volume can be mounted read-only by many nodes -- #PV可以被多個節點掛載,但是許可權是隻讀的
    ReadWriteMany(RWX) -- the volume can be mounted as read-write by many nodes -- #PV可以被多個節點以讀寫方式掛載

3 建立PV

3.1 靜態PV

PersistentVolume Spec主要支援以下幾個通用欄位，用於定義PV的容量、訪問模式和回收策略。

Capacity：當前PV的容量；目前，Capacity僅支援空間設定，將來應該還可以指定IOPS和throughput。
accessModes(訪問模式）：儘管在PV層看起來並無差別，但儲存裝置支援及啟用的功能特性卻可能不盡相同。例如NFS儲存支援多客戶端同時掛載及讀寫操作，但也可能在共享時僅啟用了只讀操作，其他儲存系統也存在類似的可配置特性。因此，PV底層點裝置或許存在其特有點訪問模式，使用者使用時必須在其特性範圍內設定其功能。
- ReadWriteOnce：僅可被單個節點只讀掛載；命令列中簡寫為RWO。
- ReadOnlyMany：可被多個節點同時只讀掛載；命令列中簡寫為ROX。
- ReadWriteMany：可被多個節點同時讀寫掛載；命令列中簡寫為RWX。
persistentVolumeReclaimPolicy（回收策略）：PV空間被釋放時的處理機制；可用型別僅為Retain（預設）、Recycle或Delete。
- Retain：保持不動，由管理員隨後手動回收。
- Recycle：空間回收，即刪除儲存卷目錄下的所有檔案（包括子目錄和隱藏檔案），目前僅NFS和hostPath支援此操作。
- Delete：刪除儲存卷，僅部分雲端儲存系統支援，如AWS EBS、GCE PD、Azure Disk和Cinder。
volumeMode：卷模型，用於指定此卷可被用作檔案系統還是裸格式的塊裝置；預設為Filesystem。
storageClassName：當前PV所屬的Storage Class的名稱；預設為空值，即不屬於任何StorageClass。
mountOptions：掛載選項組成的列表，如ro、soft、和hard等。

案例1：NFS儲存PV

#編寫資源清單
[root@ubuntu-200 ~]# cat volume-pv-nfs.yaml 
apiVersion: v1
kind: PersistentVolume
metadata: 
  name: pv-nfs-001
  labels:
    release: stabel
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  mountOptions:
   - hard
   - nfsvers=4.1
  nfs:
    server: 10.0.0.5
    path: /data/test

#建立PV
[root@ubuntu-200 ~]# kubectl apply -f volume-pv-nfs.yaml

#檢視建立的PV
[root@ubuntu-200 ~]# kubectl get pv -o wide
NAME         CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE    VOLUMEMODE
pv-nfs-001   5Gi        RWO            Retain           Available                                   110s   Filesystem

建立完成後，可以看到其狀態為“Available”，即“可用”狀態，表示目前尚未被PVC資源所繫結。

使用資源的檢視命令可列出PV資源的相關資訊。建立完成的PV資源可能處於下列四種狀態中的某一種，它們代表著PV資源生命週期中的各個階段。

Available：可用狀態的自由資源，尚未被PVC繫結。
Bound：已經繫結至某PVC。
Released：繫結的PVC已經被刪除，但資源尚未被叢集回收。
Failed：因自動回收資源失敗而處於的故障狀態。

3.2 建立PVC

定義PVC時，使用者可通過訪問模式（accessModes）、資料來源（dataSource）、儲存資源空間需要和限制（resources和limits）、儲存類、標籤選擇器和卷名稱等匹配標準來篩選叢集上的PV資源，其中，resources和accessModes是最重的篩選標準。PVC的spec欄位的可巢狀欄位有如下幾個：

accessModes <[]string>: PVC的訪問模式;它同樣支援RWO、RWX和ROX三種模式;
dataSources <Object>: 用於從指定的資料來源恢復該PVC卷,它目前支援的資料來源包括一個現在卷快照物件（snapshot.storage.k8s.io/VolumeSnapshot）、一個既有PVC物件（PersistentVolumeClaim）或一個既有的用於資料轉存點自定義資源物件（resource/object）;
resources <Object>: 宣告使用的儲存空間的最小值和最大值;目前，PVC的資源限定僅支援空間大小一個維度;
selector <Obeject>: 篩選PV時額外使用的標籤選擇器(matchLables)或匹配條件表示式(matchExpressions);
storageClassName <string>: 該PV資源隸屬的儲存類資源名稱;指定了儲存型別的PVC僅能在同一個儲存下篩選PV資源,否則,就只能從所有不具有儲存類的PV中進行篩選;
volumeMode <string>: 卷模型,用於指定此卷可被用作檔案系統還是裸格式的塊裝置;預設值是Filesystem;
volumeName <string>: 直接指定要繫結的PV資源的名稱。

範例:

#編寫PV的資源清單並建立PV
[root@ubuntu-200 ~]# cat pv-nfs-001.yaml 
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-nfs-001
  labels:
    release: redis
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Recycle
  storageClassName: slow
  mountOptions:
    - hard
    - nfsvers=4.1
  nfs:
    server: 10.0.0.58
    path: /data/test1
[root@ubuntu-200 ~]# kubectl apply -f pv-nfs-001.yaml 
persistentvolume/pv-nfs-001 created

#檢視建立的PV
[root@ubuntu-200 ~]# kubectl get pv -o wide
NAME         CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE   VOLUMEMODE
pv-nfs-001   5Gi        RWX            Recycle          Available           slow                    27s   Filesystem

#編寫PVC的資源清單並建立PVC
[root@ubuntu-200 ~]# cat pvc-001.yaml 
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-001
spec:
  accessModes:
    - ReadWriteMany
  volumeMode: Filesystem
  resources:
    requests:
      storage: 5Gi
  storageClassName: slow
  selector:
    matchLabels:
      release: "redis"
[root@ubuntu-200 ~]# kubectl apply -f pvc-001.yaml

#檢視PV和PVC,可看到已經匹配
[root@ubuntu-200 ~]# kubectl get pv
NAME         CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM             STORAGECLASS   REASON   AGE
pv-nfs-001   5Gi        RWX            Recycle          Bound    default/pvc-001   slow                    15m
[root@ubuntu-200 ~]# kubectl get pvc
NAME      STATUS   VOLUME       CAPACITY   ACCESS MODES   STORAGECLASS   AGE
pvc-001   Bound    pv-nfs-001   5Gi        RWX            slow           106s

建立 PVC資源之後，即可在Pod資源中通過persistenVolumeClain儲存卷引用它，而後掛載於容器中進行資料持久化。需要注意的是，PV是叢集級別的資源，而PVC則隸屬於名稱空間，因此，PVC在繫結目標PV時不受名稱空間的限制，但Pod引用PVC時，則只能是屬於同一名稱空間內的PVC資源。

3.3 在Pod中使用PVC

在Pod資源中呼叫PVC資源，只需要在定義volumes時使用persistentVolumeClaims欄位巢狀指定兩個欄位即可：

claimName: 要呼叫的PVC儲存卷的名稱，PVC卷要與Pod在同一名稱空間中。
readOnly：是否將儲存卷強制掛載為只讀模式，預設為flase。

範例：

#資源清單如下
[root@ubuntu-200 ~]# cat pod-redis.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: pod-redis
spec:
  containers:
  - name: redis
    image: redis:alpine
    securityContext:
      runAsUser: 1099
    ports:
    - containerPort: 6379
      name: redis-port
    volumeMounts:
    - mountPath: /data
      name: redis-vol
  volumes:
  - name: redis-vol
    persistentVolumeClaim:
      claimName: pvc-001
      
#建立pod
[root@ubuntu-200 ~]# kubectl apply -f pod-redis.yaml

#進入pod測試
[root@ubuntu-200 ~]# kubectl get pods -o wide
NAME               READY   STATUS    RESTARTS   AGE   IP            NODE         NOMINATED NODE   READINESS GATES
pod-redis          1/1     Running   0          68s   10.244.1.67   ubuntu-220   <none>           <none>
volume-nfs-redis   1/1     Running   1          13h   10.244.2.72   ubuntu-210   <none>           <none>
[root@ubuntu-200 ~]# kubectl exec -it pod-redis -- /bin/sh
/data $ redis-cli
127.0.0.1:6379> set name yang
OK
127.0.0.1:6379> get name
"yang"
127.0.0.1:6379> bgsave
Background saving started
127.0.0.1:6379> exit
/data $ ls
dump.rdb

#在nfs伺服器上檢視
[root@C8_58 ~]# ll /data/test1
total 4
-rw-r--r-- 1 redis nobody 108 Dec 10 10:34 dump.rdb

3.4 儲存類(storage class)

儲存類(storage class)是Kubenetes資源型別的一種,它是由管理員為管理PV方便而按需建立的類別(邏輯組),例如可按儲存系統的效能高低分類,例如可按儲存系統的效能高低分類，或者根據其綜合服務質量級別進行分類、依照備份策略分類，甚至直接按管理員自定義的標準進行分類等。

儲存類的好處之一便是支援PV的動態建立。使用者用到永續性儲存，需要通過建立PVC來繫結匹配的PV，此類操作需要量較大，或者當管理員手動建立的PV無法滿足PVC的需求時，系統按PVC的需要標準動態建立適配的PV會為儲存管理帶來極大的靈活性。

儲存類物件的名稱至關重要，它是使用者呼叫的標識。建立儲存類物件時，除了名稱之外，還需要為其定義三個關鍵字：provisioner、parameter和reclaimPolicy。

StorageClass Spec中五個可用欄位：

provisioner（供給方）：即提供了儲存資源的儲存系統，儲存類要依賴Provisioner來判定要使用的儲存外掛以便適配到目標儲存系統。Kubernetes內鍵有多種供給方（Provisioner），這些供給方的名字都以“kubernetes.io”為字首。另外，它還支援使用者依據Kubernetes規範自定義Provisioner。
parameters（引數）：儲存類使用引數描述要關聯到的儲存卷，不過，不同的Provisioner可用的引數各不相同。
reclaimPolicy：為當前儲存類動態建立的PV指定回收策略，可用值為Delete（預設）和Retain；不過，那些由管理員手工建立的PV的回收策略取決於它們自身的定義。
volumeBindingMode：定義如何為PVC完成供給和繫結，預設值為“VolumeBinding Immediate”；此選項僅在啟用了儲存卷排程功能時才能生效。
mountOptions：由當前類動態建立的PV的掛載選項列表。

範例：

[root@ubuntu-200 ~]# cat sc-001.yaml 
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: sc-001
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer 
#這裡的volumeBindingMode: WaitForFirstConsumer很關鍵，意思就是延遲繫結，當有符合PVC要求的PV不立即繫結。因為POD使用PVC，而繫結之後，POD被排程到其他節點，顯然其他節點很有可能沒有那個PV所以POD就掛起了，另外就算該節點有合適的PV，而POD被設定成不能執行在該節點，這時候就沒法了，延遲繫結的好處是，POD的排程要參考卷的分佈。當開始排程POD的時候看看它要求的LPV在哪裡，然後就排程到該節點，然後進行PVC的繫結，最後在掛載到POD中，這樣就保證了POD所在的節點就一定是LPV所在的節點。所以讓PVC延遲繫結，就是等到使用這個PVC的POD出現在排程器上之後（真正被排程之前），然後根據綜合評估再來繫結這個PVC。

3.5 動態PV之longhorn的使用

3.5.1 部署

(1)、前提：安裝依賴

對於Debian和Ubuntu，請使用以下命令：

# apt-get -y install open-iscsi

對於帶有的RHEL和CentOS，請使用以下命令：

# yum -y install iscsi-initiator-utils

(2)、部署

1.使用以下命令在任何Kubernetes叢集上安裝Longhorn

# kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/master/deploy/longhorn.yaml

#最好將yaml檔案下載下來
# kubectl apply -f longhorn.yaml

# weget https://raw.githubusercontent.com/longhorn/longhorn/master/deploy/longhorn.yaml

2.檢查部署是否成功:

# kubectl -n longhorn-system get pod
NAME                                        READY     STATUS    RESTARTS   AGE
csi-attacher-6fdc77c485-8wlpg               1/1       Running   0          9d
csi-attacher-6fdc77c485-psqlr               1/1       Running   0          9d
csi-attacher-6fdc77c485-wkn69               1/1       Running   0          9d
csi-provisioner-78f7db7d6d-rj9pr            1/1       Running   0          9d
csi-provisioner-78f7db7d6d-sgm6w            1/1       Running   0          9d
csi-provisioner-78f7db7d6d-vnjww            1/1       Running   0          9d
engine-image-ei-6e2b0e32-2p9nk              1/1       Running   0          9d
engine-image-ei-6e2b0e32-s8ggt              1/1       Running   0          9d
engine-image-ei-6e2b0e32-wgkj5              1/1       Running   0          9d
longhorn-csi-plugin-g8r4b                   2/2       Running   0          9d
longhorn-csi-plugin-kbxrl                   2/2       Running   0          9d
longhorn-csi-plugin-wv6sb                   2/2       Running   0          9d
longhorn-driver-deployer-788984b49c-zzk7b   1/1       Running   0          9d
longhorn-manager-nr5rs                      1/1       Running   0          9d
longhorn-manager-rd4k5                      1/1       Running   0          9d
longhorn-manager-snb9t                      1/1       Running   0          9d
longhorn-ui-67b9b6887f-n7x9q                1/1       Running   0          9d

3.修改yaml檔案暴露UI介面埠

#修改配置檔案，並將pod埠暴露出去
[root@ubuntu-200 ~]# vim longhorn.yaml
...
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: longhorn-ui
  name: longhorn-ui
  namespace: longhorn-system
spec:
  replicas: 1
  selector:
    matchLabels:
      app: longhorn-ui
  template:
    metadata:
      labels:
        app: longhorn-ui
    spec:
      containers:
      - name: longhorn-ui
        image: longhornio/longhorn-ui:v1.0.2
        imagePullPolicy: IfNotPresent
        securityContext:
          runAsUser: 0
        ports:
        - containerPort: 8000
          name: http
          hostPort: 8000    #新增此行
        env:
          - name: LONGHORN_MANAGER_IP
            value: "http://longhorn-backend:9500"
...

#重新部署
[root@ubuntu-200 ~]# kubectl apply -f longhorn.yaml

#檢視UIpod被排程到的節點
[root@ubuntu-200 ~]# kubectl get pods -o wide -n longhorn-system 
NAME                                        READY   STATUS    RESTARTS   AGE     IP            NODE         NOMINATED NODE   READINESS GATES
csi-attacher-7cb499df6-fjp5j                1/1     Running   1          3h2m    10.244.5.6    c8-48        <none>           <none>
csi-attacher-7cb499df6-hb8kk                1/1     Running   1          3h2m    10.244.1.73   ubuntu-220   <none>           <none>
csi-attacher-7cb499df6-qqzxc                1/1     Running   1          3h2m    10.244.2.81   ubuntu-210   <none>           <none>
csi-provisioner-67846b4b55-fb2rx            1/1     Running   0          3h2m    10.244.2.79   ubuntu-210   <none>           <none>
csi-provisioner-67846b4b55-n9gcj            1/1     Running   1          3h2m    10.244.1.72   ubuntu-220   <none>           <none>
csi-provisioner-67846b4b55-t2rjj            1/1     Running   1          3h2m    10.244.5.7    c8-48        <none>           <none>
csi-resizer-5cb8df7db9-6xwzd                1/1     Running   0          3h2m    10.244.1.75   ubuntu-220   <none>           <none>
csi-resizer-5cb8df7db9-q79md                1/1     Running   2          3h2m    10.244.2.78   ubuntu-210   <none>           <none>
csi-resizer-5cb8df7db9-wsmhl                1/1     Running   1          3h2m    10.244.5.8    c8-48        <none>           <none>
engine-image-ei-ee18f965-dwxsp              1/1     Running   0          3h9m    10.244.1.69   ubuntu-220   <none>           <none>
engine-image-ei-ee18f965-wntmt              1/1     Running   0          3h9m    10.244.5.4    c8-48        <none>           <none>
engine-image-ei-ee18f965-wwm28              1/1     Running   0          3h9m    10.244.2.75   ubuntu-210   <none>           <none>
instance-manager-e-45b562a8                 1/1     Running   0          3h8m    10.244.1.71   ubuntu-220   <none>           <none>
instance-manager-e-aaeb5217                 1/1     Running   0          110m    10.244.5.27   c8-48        <none>           <none>
instance-manager-e-bd5ddc65                 1/1     Running   0          3h1m    10.244.2.82   ubuntu-210   <none>           <none>
instance-manager-r-5d27c92a                 1/1     Running   0          62m     10.244.5.33   c8-48        <none>           <none>
instance-manager-r-60a7e836                 1/1     Running   0          3h1m    10.244.2.83   ubuntu-210   <none>           <none>
instance-manager-r-945e433d                 1/1     Running   0          3h8m    10.244.1.70   ubuntu-220   <none>           <none>
longhorn-csi-plugin-bk2mx                   2/2     Running   0          3h2m    10.244.5.9    c8-48        <none>           <none>
longhorn-csi-plugin-bm58t                   2/2     Running   0          3h2m    10.244.1.74   ubuntu-220   <none>           <none>
longhorn-csi-plugin-qt4qv                   2/2     Running   0          3h2m    10.244.2.80   ubuntu-210   <none>           <none>
longhorn-driver-deployer-6b7d76659f-24rqk   1/1     Running   0          3h13m   10.244.2.74   ubuntu-210   <none>           <none>
longhorn-manager-m6jh9                      1/1     Running   10         3h13m   10.244.5.2    c8-48        <none>           <none>
longhorn-manager-qczzp                      1/1     Running   1          3h13m   10.244.2.73   ubuntu-210   <none>           <none>
longhorn-manager-wmxzw                      1/1     Running   1          3h13m   10.244.1.68   ubuntu-220   <none>           <none>
longhorn-ui-5f9659448b-qddjw                1/1     Running   0          131m    10.244.5.18   c8-48        <none>           <none>

測試訪問

3.5.2 配置longhorn支援RWX

longhorn預設不支援RWX模式，需單獨配置。

官方參考文件：https://longhorn.io/docs/1.0.2/advanced-resources/rwx-workloads/

範例：

#下載官方的資源清單
01-security.yaml
02-longhorn-nfs-provisioner.yaml
github地址：https://github.com/longhorn/longhorn/tree/master/examples/rwx
#wget無法下載，會被排程到亞馬遜上

#在伺服器上安裝git，使用git clone，直接將longhorn整個檔案下載下來。
git clone https://github.com/longhorn/longhorn.git

#配置安裝
kubectl apply -f 01-security.yaml
kubectl apply -f 02-longhorn-nfs-provisioner.yaml

#檢視
[root@ubuntu-200 /data/statefulset]# kubectl get pods -n longhorn-system 
NAME                                        READY   STATUS    RESTARTS   AGE
csi-attacher-7cb499df6-68mkc                1/1     Running   2          2d1h
csi-attacher-7cb499df6-6vmg9                1/1     Running   8          2d1h
csi-attacher-7cb499df6-kmq5v                1/1     Running   3          2d1h
csi-provisioner-67846b4b55-26w66            1/1     Running   3          2d1h
csi-provisioner-67846b4b55-28vwn            1/1     Running   5          2d1h
csi-provisioner-67846b4b55-7jk8p            1/1     Running   3          2d1h
csi-resizer-5cb8df7db9-4jlzj                1/1     Running   2          2d1h
csi-resizer-5cb8df7db9-6mlxz                1/1     Running   4          2d1h
csi-resizer-5cb8df7db9-xgr2s                1/1     Running   4          2d1h
engine-image-ei-ee18f965-bdvpn              1/1     Running   2          2d1h
engine-image-ei-ee18f965-j59bs              1/1     Running   2          2d1h
engine-image-ei-ee18f965-v94qb              1/1     Running   3          2d1h
instance-manager-e-10494252                 1/1     Running   0          39m
instance-manager-e-743da98a                 1/1     Running   0          98m
instance-manager-e-847f7101                 1/1     Running   0          100m
instance-manager-r-3eb87c55                 1/1     Running   0          98m
instance-manager-r-3ed54400                 1/1     Running   0          100m
instance-manager-r-ed21a329                 1/1     Running   0          39m
longhorn-csi-plugin-6b6nj                   2/2     Running   7          2d1h
longhorn-csi-plugin-sl7w9                   2/2     Running   5          2d1h
longhorn-csi-plugin-tkl7r                   2/2     Running   7          2d1h
longhorn-driver-deployer-6b7d76659f-ns5rp   1/1     Running   2          2d1h
longhorn-manager-4dq4w                      1/1     Running   2          2d1h
longhorn-manager-d6c9s                      1/1     Running   2          2d1h
longhorn-manager-gj985                      1/1     Running   4          2d1h
longhorn-nfs-provisioner-76cb977b9f-6z84c   1/1     Running   0          91m #配置後新增
longhorn-ui-5f9659448b-bt8mh                1/1     Running   2          2d1h