K8S存储之PV和PVC
1 介绍
对于管理计算资源来说，管理存储资源明显是另一个问题。PersistentVolume子系统为用户和管理员提供了一个API，该API将如何提供存储点细节抽象了出来。为此，我们引入两个新的API资源：PersistentVolume和PersistentVolumeClaim。
持久卷（PersistentVolume，PV）是由管理员设置的存储，可以由管理员事先供应，或者使用存储类（Storage Class）来动态供应。持久卷是集群资源，就像节点也是集群资源一样。PV持久卷和普通的Volume一样，也是使用卷插件来实现的，只是它们拥有独立于任何使用PV的Pod的生命周期。此API对象中记述了存储的实现细节，无论背后是NFS、iSCSI还是特定于云平台的存储系统。
尽管 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
