K8S存儲之PV和PVC

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

# wget 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