探索 Kubernetes 持久化存储之 Longhorn 初窥门径

作者：运维有术星主

在 Kubernetes 生态体系中，持久化存储扮演着至关紧张的角色，它是支撑业务应用稳定运行的基石。对于那些选择自建 Kubernetes 集群的运维架构师而言，选择合适的后端持久化存储解决方案是一项至关紧张的选型决策。现在 Ceph、GlusterFS、NFS、openEBS 等解决方案已被广泛采用。
往期文章，我分享过最简单、实用的 探索 Kubernetes 持久化存储之 NFS 终极实战指南。
为了丰富我们的技能栈，并为未来的容器云平台设计持久化存储提供更多灵活性和选择性。本日，我将跟大家一起探索，如何将 Longhorn 集成至 KubeSphere 管理的 Kubernetes 集群。
本文核心内容概览：

• Longhorn 持久化存储选型说明： 聊一聊 Longhorn 初体验的感想
  
• Longhorn 存储服务如何部署： 如果使用 Helm 安装 Longhorn
  
• 实战演示：创建测试资源，体验 Longhorn 的效果。
  

实战服务器配置(架构 1:1 复刻小规模生产情况，配置略有不同)
主机名IPCPU内存体系盘数据盘用途ksp-registry192.168.9.904840200Harbor 镜像仓库ksp-control-1192.168.9.914840100KubeSphere/k8s-control-planeksp-control-2192.168.9.924840100KubeSphere/k8s-control-planeksp-control-3192.168.9.934840100KubeSphere/k8s-control-planeksp-worker-1192.168.9.9441640100k8s-worker/CIksp-worker-2192.168.9.9541640100k8s-workerksp-worker-3192.168.9.9641640100k8s-workerksp-storage-1192.168.9.974840400+Containerd、OpenEBS、ElasticSearch/Longhorn/Ceph/NFSksp-storage-2192.168.9.984840300+Containerd、OpenEBS、ElasticSearch/Longhorn/Cephksp-storage-3192.168.9.994840300+Containerd、OpenEBS、ElasticSearch/Longhorn/Cephksp-gpu-worker-1192.168.9.10141640100k8s-worker(GPU NVIDIA Tesla M40 24G)ksp-gpu-worker-2192.168.9.10241640100k8s-worker(GPU NVIDIA Tesla P100 16G)ksp-gateway-1192.168.9.1032440自建应用服务代理网关/VIP：192.168.9.100ksp-gateway-2192.168.9.1042440自建应用服务代理网关/VIP：192.168.9.100ksp-mid192.168.9.1054840100部署在 k8s 集群之外的服务节点（Gitlab 等）合计15561526002100+实战情况涉及软件版本信息

• 操作体系：openEuler 22.03 LTS SP3 x86_64
  
• KubeSphere：v3.4.1
  
• Kubernetes：v1.28.8
  
• KubeKey: v3.1.1
  
• Containerd：1.7.13
  
• NVIDIA GPU Operator：v24.3.0
  
• NVIDIA 显卡驱动：550.54.15
  
• Longhorn：v1.6.2
  

1. Longhorn 初体验

为了贴近生产需求，我在规划部署时增加了一些想法：
想法 1: 存储节点规划：

• 向 Kubernetes 集群增加三个节点，专门用于 Longhorn 存储服务
  
• Longhorn 存储服务所有组件和数据盘都部署在专属节点
  
• 每个存储节点打上专属标签 kubernetes.io/storage=longhorn，部署 Longhorn 服务时使用 nodeSelector 指定节点标签 （不指定会默认使用所有 Worker 节点）
  
• 业务负载部署在集群中其他 Worker 节点，使用 Longhorn 提供的持久化存储
  

想法 2: 存储空间使用规划：

• 每个存储节点添加一块 Longhorn 专用的 100G 数据盘 /dev/sdc，使用 LVM 范例将其格式化，挂载到 /longhorn 目次
  
• 更改 Longhorn 默认存储路径 /var/lib/longhorn 为 /longhorn
  

很遗憾，在实际部署 Longhorn 时，想法 1 没有完全实现，Longhorn 存储服务所有组件可以部署在指定节点，后期创建 Pod 测试时发现，当 Pod 分配的 Worker 节点不安装 Longhorn CSI 插件，Pod 创建异常。但是，Longhorn CSI 插件又无法独立安装（也可能我技能太菜，没找到）。
最终，为了按规划完成部署，我执行了以下操作：

• 部署测试时分别体验了 Kubectl 和 Helm 两种方式，最终成文时选择了 Helm
  
• Helm 部署时使用 set 参数指定自界说默认存储路径、指定 nodeSelector 部署所有 Longhorn 组件
  
• 创建测试 Pod 时，也带上 nodeSelector 标签（运行在其他 Worker 节点的 Pod，无法使用 Longhorn 存储）
  

整个部署过程比力艰辛，使用 Helm 部署失败或是部署过程异常终止后，想要卸载很难、很麻烦。
简单的说几句 Longhorn 初体验后的想法（仅代表个人观点）：

• 因为加了自界说规划的想法，所以，初次体验感较差。
  
• 对于新手而言，按照官方文档使用默认配置部署，能得到较好的 Longhorn 初体验（实测）
  
• Longhorn 有自身的特性优点，发展至今已经存在肯定的生产用户。但是，没有肯定的技能气力，不建议碰 Longhorn
  
• 可以部署体验，相识 Longhorn 是什么样子，能提供什么，有什么优秀特性
  
• 官方文档资料看着很多，但是实际使用中出现题目的话，能搜到的可参考文档太少，没肯定的技能底蕴，还是不要碰了
  
• 现在来看，替代 GlusterFS、NFS 的持久化存储方案，我宁可选择去征服 Ceph 也不会选择 Longhorn（Ceph 更成熟，文档资料更多，得到技能支持的途径多）
  

紧张说明：

• 由于部署过程中，定制化配置的结果不尽人意。所以，本文最终变成了浅尝辄止、抛砖引玉之作。接待各位 Longhorn 专家，留言、赐教。
  
• 本文的内容对于安装部署 Longhorn 有肯定的鉴戒意义，但是 切勿将本文的实战过程用于任何范例的正式情况。
  

2. 前置条件

2.1 扩容存储专用 Worker 节点

将新增的三台存储专用节点加入已有的 Kubernetes 集群，详细的扩容操作请参考 KubeKey 扩容 Kubernetes Worker 节点实战指南。
2.2 初始化数据盘

按规划将 /dev/sdc 初始化，编辑文件 /etc/fstab，将 /longhorn 目次对应的磁盘配置为开机自动挂载。
LVM 配置比力简单，操作细节不做表明，直接上命令。

1. pvcreate /dev/sdc
2. vgcreate longhorn /dev/sdc
3. lvcreate -l 100%VG longhorn -n data
4. mkfs.xfs /dev/mapper/longhorn-data
5. mkdir /longhorn
6. mount /dev/mapper/longhorn-data /longhorn
7. tail -1 /etc/mtab >> /etc/fstab

复制代码

2.3 安装 NFSv4 客户端

在 Longhorn 体系中, 备份功能需要 NFSv4, v4.1 或是 v4.2, 同时， ReadWriteMany (RWX) 卷功能需要 NFSv4.1。因此，需要提前安装 NFSv4 客户端。

1. yum install nfs-utils

复制代码

2.4 安装 open-iscsi

必要组件，Longhorn 依赖主机上的 iscsiadm 向 Kubernetes 提供持久卷。

1. yum --setopt=tsflags=noscripts install iscsi-initiator-utils
2. echo "InitiatorName=$(/sbin/iscsi-iname)" > /etc/iscsi/initiatorname.iscsi
3. systemctl enable iscsid
4. systemctl start iscsid

复制代码

2.5 检查 Kubernetes 版本

执行以下命令检查 Kubernetes 版本，确保输出结果中 Server Version 大于等于 v1.21。

1. $ kubectl version
2. Client Version: v1.28.8
3. Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
4. Server Version: v1.28.8

复制代码

2.6 使用情况检查脚本

Longhorn 官方编写了一个 shell 脚本，帮助我们搜集评估集群情况是否满足部署要求。

• 在 Control-1 节点下载脚本
  

1. curl -sSfL https://raw.githubusercontent.com/longhorn/longhorn/v1.6.2/scripts/environment_check.sh -o environment_check.sh

复制代码

• 执行脚本
  

1. sh environment_check.sh

复制代码

精确执行后，输出结果如下 :

1. $ sh environment_check.sh
2. [INFO]  Required dependencies 'kubectl jq mktemp sort printf' are installed.
3. [INFO]  All nodes have unique hostnames.
4. [INFO]  Waiting for longhorn-environment-check pods to become ready (0/0)...
5. [INFO]  All longhorn-environment-check pods are ready (8/8).
6. [INFO]  MountPropagation is enabled
7. [INFO]  Checking kernel release...
8. [INFO]  Checking iscsid...
9. [INFO]  Checking multipathd...
10. [INFO]  Checking packages...
11. [INFO]  Checking nfs client...
12. [INFO]  Cleaning up longhorn-environment-check pods...
13. [INFO]  Cleanup completed.

复制代码

情况检查过程及结果简要说明：

• 该脚本执行过程中会从 DockerHub 下载 alpine:3.12 镜像，用于测试。如果下载失败，请自行修改为能正常下载的镜像地点。
  
• 该脚本会在所有 Worker 节点下载 longhorn-environment-check pods，并执行相应的检查命令
  
• 建议所有 Worker 节点体系内核大于等于 5.8，提前安装 NFSv4 客户端、安装 open-iscsi
  

确保所有配置满足前置条件要求，情况检查脚本检测乐成后。接下来，我们正式开始安装 Longhorn 组件。
3. 安装配置 Longhorn

Longhorn 官方文档中提供多种安装方式的帮助文档：

• Install as a Rancher Apps & Marketplace
  
• Install with Kubectl
  
• Install with Helm
  
• Install with Fleet
  
• Install with Flux
  
• Install with ArgoCD
  
• Air Gap Installation
  

我最初的计划是，实战演示使用原生的 Kubectl 客户端安装 Longhorn。无奈在部署过程中遇到了自界说配置困难的题目，虽然能搞，但是有点麻烦，最终没有找到灵活、简单的方案。所以，最终成文时改成了 Helm 方式。
3.1 设置存储标签

• 按规划给三个存储节点打上专属标签
  

1. kubectl label nodes ksp-storage-1 kubernetes.io/storage=longhorn
2. kubectl label nodes ksp-storage-2 kubernetes.io/storage=longhorn
3. kubectl label nodes ksp-storage-3 kubernetes.io/storage=longhorn

复制代码

3.2 使用 Helm 安装部署 Longhorn

• 添加 Longhorn Helm repository
  

1. helm repo add longhorn https://charts.longhorn.io

复制代码

• 从 Repository 拉取最新的 Charts
  

1. helm repo update

复制代码

• 官方默认的部署命令（本文未用，建议新手使用）
  

1. helm install longhorn longhorn/longhorn --namespace longhorn-system --create-namespace --version 1.6.2

复制代码

• 根据部署规划，执行自界说部署命令
  

1. helm install longhorn2 longhorn/longhorn \
2.   --namespace longhorn-system \
3.   --create-namespace \
4.   --version 1.6.2 \
5.   --set defaultSettings.defaultDataPath="/longhorn" \
6.   --set defaultSettings.systemManagedComponentsNodeSelector="kubernetes.io/storage:longhorn" \
7.   --set longhornManager.nodeSelector."kubernetes\.io/storage"=longhorn \
8.   --set longhornUI.nodeSelector."kubernetes\.io/storage"=longhorn \
9.   --set longhornDriver.nodeSelector."kubernetes\.io/storage"=longhorn

复制代码

• 检查 Longhorn 部署结果
  

1. $ kubectl -n longhorn-system get pod

复制代码

精确部署，输出结果如下 :

1. $ kubectl -n longhorn-system get pod -o wide
2. NAME                                                READY   STATUS    RESTARTS   AGE     IP             NODE            NOMINATED NODE   READINESS GATES
3. csi-attacher-fffb968d8-gnj58                        1/1     Running   0          4m58s   10.233.77.66   ksp-storage-3   <none>           <none>
4. csi-attacher-fffb968d8-pk2vq                        1/1     Running   0          4m58s   10.233.73.59   ksp-storage-2   <none>           <none>
5. csi-attacher-fffb968d8-w6rfh                        1/1     Running   0          4m58s   10.233.64.62   ksp-storage-1   <none>           <none>
6. csi-provisioner-745d97cc98-2r96q                    1/1     Running   0          4m58s   10.233.64.63   ksp-storage-1   <none>           <none>
7. csi-provisioner-745d97cc98-n9drv                    1/1     Running   0          4m57s   10.233.77.67   ksp-storage-3   <none>           <none>
8. csi-provisioner-745d97cc98-zvn7b                    1/1     Running   0          4m57s   10.233.73.60   ksp-storage-2   <none>           <none>
9. csi-resizer-58c5999fd6-5982f                        1/1     Running   0          4m57s   10.233.73.61   ksp-storage-2   <none>           <none>
10. csi-resizer-58c5999fd6-7z4m9                        1/1     Running   0          4m57s   10.233.64.64   ksp-storage-1   <none>           <none>
11. csi-resizer-58c5999fd6-zxszp                        1/1     Running   0          4m57s   10.233.77.68   ksp-storage-3   <none>           <none>
12. csi-snapshotter-5d995448d9-7tcrn                    1/1     Running   0          4m57s   10.233.77.69   ksp-storage-3   <none>           <none>
13. csi-snapshotter-5d995448d9-l84vr                    1/1     Running   0          4m57s   10.233.64.65   ksp-storage-1   <none>           <none>
14. csi-snapshotter-5d995448d9-v9c54                    1/1     Running   0          4m57s   10.233.73.62   ksp-storage-2   <none>           <none>
15. engine-image-ei-ffd6ed9b-8f6k7                      1/1     Running   0          5m7s    10.233.77.63   ksp-storage-3   <none>           <none>
16. engine-image-ei-ffd6ed9b-x2ld9                      1/1     Running   0          5m7s    10.233.73.57   ksp-storage-2   <none>           <none>
17. engine-image-ei-ffd6ed9b-zdpsb                      1/1     Running   0          5m7s    10.233.64.60   ksp-storage-1   <none>           <none>
18. instance-manager-561847cbad61a658e57dbb9aa2ea827d   1/1     Running   0          5m7s    10.233.77.64   ksp-storage-3   <none>           <none>
19. instance-manager-74249bf3bf13f051b14d39af24d9e46c   1/1     Running   0          5m7s    10.233.64.61   ksp-storage-1   <none>           <none>
20. instance-manager-f7b59324b33e30e62b1aacf332a7c3c1   1/1     Running   0          5m7s    10.233.73.58   ksp-storage-2   <none>           <none>
21. longhorn-csi-plugin-jknqd                           3/3     Running   0          4m57s   10.233.73.63   ksp-storage-2   <none>           <none>
22. longhorn-csi-plugin-l7px4                           3/3     Running   0          4m57s   10.233.77.70   ksp-storage-3   <none>           <none>
23. longhorn-csi-plugin-m5bcp                           3/3     Running   0          4m57s   10.233.64.66   ksp-storage-1   <none>           <none>
24. longhorn-driver-deployer-55c5f59d77-xz5vd           1/1     Running   0          5m14s   10.233.77.61   ksp-storage-3   <none>           <none>
25. longhorn-manager-nxks5                              1/1     Running   0          5m14s   10.233.77.62   ksp-storage-3   <none>           <none>
26. longhorn-manager-r7qf6                              1/1     Running   0          5m14s   10.233.64.58   ksp-storage-1   <none>           <none>
27. longhorn-manager-xbgtd                              1/1     Running   0          5m14s   10.233.73.55   ksp-storage-2   <none>           <none>
28. longhorn-ui-6fd7f57659-ff7wl                        1/1     Running   0          5m14s   10.233.64.59   ksp-storage-1   <none>           <none>
29. longhorn-ui-6fd7f57659-v6kpb                        1/1     Running   0          5m14s   10.233.73.56   ksp-storage-2   <none>           <none>

复制代码

留意：上述配置虽然实现了所有组件都部署在专属存储节点上。但是，实际无法正常使用，调理在集群其他节点的 Pod 根本无法使用 Longhorn 提供的存储。

3.3 开启 UI

官方默认的 Longhorn UI，没有开启认证功能，开启即袒露所有能力。官方现在给出的加密认证方案，需要配合 Ingress controller 使用。
本文只是属于体验测试情况，也没打算在测试、生产情况使用。因此直接使用 nodePort 放开 Longhorn UI 服务。
更多信息请参考官方文档， 创建一个具有基本认证功能的 NGINX Ingress 控制器。

• 编辑使用 NodePort 范例的 svc 资源清单，vi longhorn-ui-svc.yaml
  

1. kind: Service
2. apiVersion: v1
3. metadata:
4.   name: longhorn-ui-nodeport
5.   namespace: longhorn-system
6.   labels:
7.     app: longhorn-ui
8. spec:
9.   ports:
10.     - name: http
11.       protocol: TCP
12.       port: 80
13.       targetPort: http
14.       nodePort: 32222
15.   selector:
16.     app: longhorn-ui
17.   clusterIP:
18.   type: NodePort

复制代码

• 创建 svc
  

1. kubectl apply -f longhorn-ui-svc.yaml

复制代码

• 访问 Longhorn UI
  

打开浏览器访问，http://集群任意节点IP:32222

4. 验证测试

4.1 创建测试 PVC

• 编写测试 PVC 资源清单，vi test-pvc-longhorn.yaml
  

1. kind: PersistentVolumeClaim
2. apiVersion: v1
3. metadata:
4.   name: test-pvc-longhorn
5. spec:
6.   storageClassName: longhorn
7.   accessModes:
8.     - ReadWriteMany
9.   resources:
10.     requests:
11.       storage: 2Gi

复制代码

• 创建 PVC
  

1. kubectl apply -f test-pvc-longhorn.yaml

复制代码

• 检察 PVC
  

1. $ kubectl get pvc -o wide
2. NAME                STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE   VOLUMEMODE
3. test-pvc-longhorn   Bound    pvc-d5a7fc28-2e4c-4f9d-b4d7-7cb7ca5a7ea7   2Gi        RWX            longhorn       7s    Filesystem

复制代码

4.2 创建测试 Pod

为了正常完成测试，创建 Pod 时指定 nodeSelector 标签，将 Pod 创建在 Longhorn 专用节点。

• 编写测试 Pod 资源清单，vi test-pod-longhorn.yaml
  

1. kind: Pod
2. apiVersion: v1
3. metadata:
4.   name: test-pod-longhorn
5. spec:
6.   containers:
7.   - name: test-pod-longhorn
8.     image: busybox:stable
9.     command:
10.       - "/bin/sh"
11.     args:
12.       - "-c"
13.       - "touch /mnt/SUCCESS && sleep 3600"
14.     volumeMounts:
15.       - name: longhorn-pvc
16.         mountPath: "/mnt"
17.   restartPolicy: "Never"
18.   nodeSelector:
19.     kubernetes.io/storage: longhorn
20.   volumes:
21.     - name: longhorn-pvc
22.       persistentVolumeClaim:
23.         claimName: test-pvc-longhorn

复制代码

• 创建 Pod
  

1. kubectl apply -f test-pod-longhorn.yaml

复制代码

• 检察 Pod
  

1. $ kubectl get pods -o wide
2. NAME                READY   STATUS    RESTARTS   AGE   IP             NODE            NOMINATED NODE   READINESS GATES
3. test-pod-longhorn   1/1     Running   0          51s   10.233.73.80   ksp-storage-2   <none>           <none>

复制代码

• 检察 Pod 挂载的存储
  

1. $ kubectl exec test-pod-longhorn -- df -h
2. Filesystem                Size      Used Available Use% Mounted on
3. overlay                  99.9G      4.7G     95.2G   5% /
4. tmpfs                    64.0M         0     64.0M   0% /dev
5. tmpfs                     3.6G         0      3.6G   0% /sys/fs/cgroup
6. 10.233.57.220:/pvc-d5a7fc28-2e4c-4f9d-b4d7-7cb7ca5a7ea7
7.                           1.9G         0      1.9G   0% /mnt
8. /dev/mapper/openeuler-root
9.                          34.2G      2.3G     30.2G   7% /etc/hosts
10. /dev/mapper/openeuler-root
11.                          34.2G      2.3G     30.2G   7% /dev/termination-log
12. /dev/mapper/data-lvdata
13.                          99.9G      4.7G     95.2G   5% /etc/hostname
14. /dev/mapper/data-lvdata
15.                          99.9G      4.7G     95.2G   5% /etc/resolv.conf
16. shm                      64.0M         0     64.0M   0% /dev/shm
17. tmpfs                     6.4G     12.0K      6.4G   0% /var/run/secrets/kubernetes.io/serviceaccount
18. tmpfs                     3.6G         0      3.6G   0% /proc/acpi
19. tmpfs                    64.0M         0     64.0M   0% /proc/kcore
20. tmpfs                    64.0M         0     64.0M   0% /proc/keys
21. tmpfs                    64.0M         0     64.0M   0% /proc/timer_list
22. tmpfs                    64.0M         0     64.0M   0% /proc/sched_debug
23. tmpfs                     3.6G         0      3.6G   0% /proc/scsi
24. tmpfs                     3.6G         0      3.6G   0% /sys/firmware

复制代码

• 测试存储空间读写
  

1. # 写入 1GB 的数据
2. $ kubectl exec test-pod-longhorn -- dd if=/dev/zero of=/mnt/test-disk.img bs=1M count=1000
3. 1000+0 records in
4. 1000+0 records out
5. 1048576000 bytes (1000.0MB) copied, 5.670424 seconds, 176.4MB/s
7. # 查看结果
8. $ kubectl exec test-pod-longhorn -- ls -lh /mnt/
9. [root@ksp-control-1 srv]# kubectl exec test-pod-longhorn -- ls -lh /mnt/
10. total 1000M
11. -rw-r--r--    1 root     root           0 Jul 17 01:03 SUCCESS
12. drwx------    2 root     root       16.0K Jul 17 01:03 lost+found
13. -rw-r--r--    1 root     root     1000.0M Jul 17 01:04 test-disk.img
15. # 测试超限（再写入 1GB 数据）
16. $ kubectl exec test-pod-longhorn -- dd if=/dev/zero of=/mnt/test-disk2.img bs=1M count=1000
17. dd: /mnt/test-disk2.img: No space left on device
18. command terminated with exit code 1

复制代码

留意：测试时，我们写入了 2G 的数据量，当达过我们创建的 PVC 2G 容量上限时会报错（实际使用写不满 2G）。说明，Longhorn 存储可以做到容量配额限定。

4.3 检察底层存储信息

测试并不充分，只是简单看看。在存储服务器（ ksp-storage-1 节点），执行以下命令。

1. $ ls -lR /longhorn/
2. /longhorn/:
3. total 4
4. -rw-r--r-- 1 root root 51 Jul 16 11:18 longhorn-disk.cfg
5. drwxr-xr-x 3 root root 63 Jul 17 01:02 replicas
7. /longhorn/replicas:
8. total 0
9. drwx------ 2 root root 108 Jul 17 01:03 pvc-d5a7fc28-2e4c-4f9d-b4d7-7cb7ca5a7ea7-3a7acff9
11. /longhorn/replicas/pvc-d5a7fc28-2e4c-4f9d-b4d7-7cb7ca5a7ea7-3a7acff9:
12. total 2075652
13. -rw------- 1 root root       4096 Jul 17 01:06 revision.counter
14. -rw-r--r-- 1 root root 2147483648 Jul 17 01:06 volume-head-000.img
15. -rw-r--r-- 1 root root        126 Jul 17 01:02 volume-head-000.img.meta
16. -rw-r--r-- 1 root root        142 Jul 17 01:03 volume.meta

复制代码

留意：Longhorn 的存储目次，跟 NFS 存储不一样，无法直接检察原始文件，使用上更安全，但是如果 Longhorn 异常，想要找回数据也更麻烦。

4.4 清算测试资源

• 清算测试 Pod、PVC
  

1. kubectl delete -f test-pod-longhorn.yaml -f test-pvc-longhorn.yaml

复制代码

• 在存储服务器（ ksp-storage-1 节点）检察数据目次
  

1. $ ls -lR /longhorn/replicas/
2. /longhorn/replicas/:
3. total 0

复制代码

从结果中可以看到，Kubernetes 删除 PVC 后，Longhorn 存储层立即删除 PVC 对应的数据目次及数据（是否能配置默认保留，暂未研究，理论上应该会有）。
4.5 测试异常说明

创建 Pod，不指定 nodeSelector 标签，Pod 会随机分配，当分配在没有安装 Longhorn CSI 插件的节点时，创建失败，异常如下。

为避免出现上述题目，建议在部署 Longhorn 时遵循默认配置，以实如今所有 Worker 节点上自动部署所需的服务组件。
5. KubeSphere 控制台管理存储资源

5.1 管理存储类

在控制台左侧功能菜单，依次选择「集群」->「存储」->「存储类」。

5.2 检察持久卷声明

Step 1: 在控制台左侧功能菜单，依次选择「集群」->「存储」->「持久卷声明」。

Step 2: 检察创建的 PVC、PV 及详情。
结果中可以显示 PVC 的存储总容量、剩余容量、已使用百分比、Inode 用量百分比。

6. Longhorn UI 概览

Longhorn UI 虽然界面简单，但是能满足日常管理的需要，能在界面实现分配存储资源、管理，实现 Longhorn 服务的基本配置管理，下面展示几张截图，作为本文的结尾。

• Dashboard
  

• Node 信息
  

• Volume 信息
  

• Setting 配置页
  

免责声明：

• 笔者程度有限，尽管经过多次验证和检查，尽力确保内容的准确性，但仍可能存在疏漏之处。敬请业界专家大佬不吝指教。
  
• 本文所述内容仅通过实战情况验证测试，读者可学习、鉴戒，但严禁直接用于生产情况。由此引发的任何题目，作者概不负责！
  

本文由博客一文多发平台 OpenWrite 发布！

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。