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

news2024/11/20 6:34:47

作者：运维有术星主

在 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-plane
ksp-control-2192.168.9.924840100KubeSphere/k8s-control-plane
ksp-control-3192.168.9.934840100KubeSphere/k8s-control-plane
ksp-worker-1192.168.9.9441640100k8s-worker/CI
ksp-worker-2192.168.9.9541640100k8s-worker
ksp-worker-3192.168.9.9641640100k8s-worker
ksp-storage-1192.168.9.974840400+Containerd、OpenEBS、ElasticSearch/Longhorn/Ceph/NFS
ksp-storage-2192.168.9.984840300+Containerd、OpenEBS、ElasticSearch/Longhorn/Ceph
ksp-storage-3192.168.9.994840300+Containerd、OpenEBS、ElasticSearch/Longhorn/Ceph
ksp-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.100
ksp-gateway-2192.168.9.1042440自建应用服务代理网关/VIP：192.168.9.100
ksp-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 配置比较简单，操作细节不做解释，直接上命令。

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

2.3 安装 NFSv4 客户端

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

yum install nfs-utils

2.4 安装 open-iscsi

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

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

2.5 检查 Kubernetes 版本

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

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

2.6 使用环境检查脚本

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

  • 在 Control-1 节点下载脚本
curl -sSfL https://raw.githubusercontent.com/longhorn/longhorn/v1.6.2/scripts/environment_check.sh -o environment_check.sh
  • 执行脚本
sh environment_check.sh

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

$ sh environment_check.sh
[INFO]  Required dependencies 'kubectl jq mktemp sort printf' are installed.
[INFO]  All nodes have unique hostnames.
[INFO]  Waiting for longhorn-environment-check pods to become ready (0/0)...
[INFO]  All longhorn-environment-check pods are ready (8/8).
[INFO]  MountPropagation is enabled
[INFO]  Checking kernel release...
[INFO]  Checking iscsid...
[INFO]  Checking multipathd...
[INFO]  Checking packages...
[INFO]  Checking nfs client...
[INFO]  Cleaning up longhorn-environment-check pods...
[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 设置存储标签

  • 按规划给三个存储节点打上专属标签
kubectl label nodes ksp-storage-1 kubernetes.io/storage=longhorn
kubectl label nodes ksp-storage-2 kubernetes.io/storage=longhorn
kubectl label nodes ksp-storage-3 kubernetes.io/storage=longhorn

3.2 使用 Helm 安装部署 Longhorn

  • 添加 Longhorn Helm repository
helm repo add longhorn https://charts.longhorn.io
  • 从 Repository 拉取最新的 Charts
helm repo update
  • 官方默认的部署命令（本文未用，建议新手使用）
helm install longhorn longhorn/longhorn --namespace longhorn-system --create-namespace --version 1.6.2
  • 根据部署规划，执行自定义部署命令
helm install longhorn2 longhorn/longhorn \
  --namespace longhorn-system \
  --create-namespace \
  --version 1.6.2 \
  --set defaultSettings.defaultDataPath="/longhorn" \
  --set defaultSettings.systemManagedComponentsNodeSelector="kubernetes.io/storage:longhorn" \
  --set longhornManager.nodeSelector."kubernetes\.io/storage"=longhorn \
  --set longhornUI.nodeSelector."kubernetes\.io/storage"=longhorn \
  --set longhornDriver.nodeSelector."kubernetes\.io/storage"=longhorn
  • 检查 Longhorn 部署结果
$ kubectl -n longhorn-system get pod

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

$ kubectl -n longhorn-system get pod -o wide
NAME                                                READY   STATUS    RESTARTS   AGE     IP             NODE            NOMINATED NODE   READINESS GATES
csi-attacher-fffb968d8-gnj58                        1/1     Running   0          4m58s   10.233.77.66   ksp-storage-3   <none>           <none>
csi-attacher-fffb968d8-pk2vq                        1/1     Running   0          4m58s   10.233.73.59   ksp-storage-2   <none>           <none>
csi-attacher-fffb968d8-w6rfh                        1/1     Running   0          4m58s   10.233.64.62   ksp-storage-1   <none>           <none>
csi-provisioner-745d97cc98-2r96q                    1/1     Running   0          4m58s   10.233.64.63   ksp-storage-1   <none>           <none>
csi-provisioner-745d97cc98-n9drv                    1/1     Running   0          4m57s   10.233.77.67   ksp-storage-3   <none>           <none>
csi-provisioner-745d97cc98-zvn7b                    1/1     Running   0          4m57s   10.233.73.60   ksp-storage-2   <none>           <none>
csi-resizer-58c5999fd6-5982f                        1/1     Running   0          4m57s   10.233.73.61   ksp-storage-2   <none>           <none>
csi-resizer-58c5999fd6-7z4m9                        1/1     Running   0          4m57s   10.233.64.64   ksp-storage-1   <none>           <none>
csi-resizer-58c5999fd6-zxszp                        1/1     Running   0          4m57s   10.233.77.68   ksp-storage-3   <none>           <none>
csi-snapshotter-5d995448d9-7tcrn                    1/1     Running   0          4m57s   10.233.77.69   ksp-storage-3   <none>           <none>
csi-snapshotter-5d995448d9-l84vr                    1/1     Running   0          4m57s   10.233.64.65   ksp-storage-1   <none>           <none>
csi-snapshotter-5d995448d9-v9c54                    1/1     Running   0          4m57s   10.233.73.62   ksp-storage-2   <none>           <none>
engine-image-ei-ffd6ed9b-8f6k7                      1/1     Running   0          5m7s    10.233.77.63   ksp-storage-3   <none>           <none>
engine-image-ei-ffd6ed9b-x2ld9                      1/1     Running   0          5m7s    10.233.73.57   ksp-storage-2   <none>           <none>
engine-image-ei-ffd6ed9b-zdpsb                      1/1     Running   0          5m7s    10.233.64.60   ksp-storage-1   <none>           <none>
instance-manager-561847cbad61a658e57dbb9aa2ea827d   1/1     Running   0          5m7s    10.233.77.64   ksp-storage-3   <none>           <none>
instance-manager-74249bf3bf13f051b14d39af24d9e46c   1/1     Running   0          5m7s    10.233.64.61   ksp-storage-1   <none>           <none>
instance-manager-f7b59324b33e30e62b1aacf332a7c3c1   1/1     Running   0          5m7s    10.233.73.58   ksp-storage-2   <none>           <none>
longhorn-csi-plugin-jknqd                           3/3     Running   0          4m57s   10.233.73.63   ksp-storage-2   <none>           <none>
longhorn-csi-plugin-l7px4                           3/3     Running   0          4m57s   10.233.77.70   ksp-storage-3   <none>           <none>
longhorn-csi-plugin-m5bcp                           3/3     Running   0          4m57s   10.233.64.66   ksp-storage-1   <none>           <none>
longhorn-driver-deployer-55c5f59d77-xz5vd           1/1     Running   0          5m14s   10.233.77.61   ksp-storage-3   <none>           <none>
longhorn-manager-nxks5                              1/1     Running   0          5m14s   10.233.77.62   ksp-storage-3   <none>           <none>
longhorn-manager-r7qf6                              1/1     Running   0          5m14s   10.233.64.58   ksp-storage-1   <none>           <none>
longhorn-manager-xbgtd                              1/1     Running   0          5m14s   10.233.73.55   ksp-storage-2   <none>           <none>
longhorn-ui-6fd7f57659-ff7wl                        1/1     Running   0          5m14s   10.233.64.59   ksp-storage-1   <none>           <none>
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
kind: Service
apiVersion: v1
metadata:
  name: longhorn-ui-nodeport
  namespace: longhorn-system
  labels:
    app: longhorn-ui
spec:
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: http
      nodePort: 32222
  selector:
    app: longhorn-ui
  clusterIP:
  type: NodePort
  • 创建 svc
kubectl apply -f longhorn-ui-svc.yaml
  • 访问 Longhorn UI

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

4. 验证测试

4.1 创建测试 PVC

  • 编写测试 PVC 资源清单，vi test-pvc-longhorn.yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: test-pvc-longhorn
spec:
  storageClassName: longhorn
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 2Gi
  • 创建 PVC
kubectl apply -f test-pvc-longhorn.yaml
  • 查看 PVC
$ kubectl get pvc -o wide
NAME                STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE   VOLUMEMODE
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
kind: Pod
apiVersion: v1
metadata:
  name: test-pod-longhorn
spec:
  containers:
  - name: test-pod-longhorn
    image: busybox:stable
    command:
      - "/bin/sh"
    args:
      - "-c"
      - "touch /mnt/SUCCESS && sleep 3600"
    volumeMounts:
      - name: longhorn-pvc
        mountPath: "/mnt"
  restartPolicy: "Never"
  nodeSelector:
    kubernetes.io/storage: longhorn
  volumes:
    - name: longhorn-pvc
      persistentVolumeClaim:
        claimName: test-pvc-longhorn
  • 创建 Pod
kubectl apply -f test-pod-longhorn.yaml
  • 查看 Pod
$ kubectl get pods -o wide
NAME                READY   STATUS    RESTARTS   AGE   IP             NODE            NOMINATED NODE   READINESS GATES
test-pod-longhorn   1/1     Running   0          51s   10.233.73.80   ksp-storage-2   <none>           <none>
  • 查看 Pod 挂载的存储
$ kubectl exec test-pod-longhorn -- df -h
Filesystem                Size      Used Available Use% Mounted on
overlay                  99.9G      4.7G     95.2G   5% /
tmpfs                    64.0M         0     64.0M   0% /dev
tmpfs                     3.6G         0      3.6G   0% /sys/fs/cgroup
10.233.57.220:/pvc-d5a7fc28-2e4c-4f9d-b4d7-7cb7ca5a7ea7
                          1.9G         0      1.9G   0% /mnt
/dev/mapper/openeuler-root
                         34.2G      2.3G     30.2G   7% /etc/hosts
/dev/mapper/openeuler-root
                         34.2G      2.3G     30.2G   7% /dev/termination-log
/dev/mapper/data-lvdata
                         99.9G      4.7G     95.2G   5% /etc/hostname
/dev/mapper/data-lvdata
                         99.9G      4.7G     95.2G   5% /etc/resolv.conf
shm                      64.0M         0     64.0M   0% /dev/shm
tmpfs                     6.4G     12.0K      6.4G   0% /var/run/secrets/kubernetes.io/serviceaccount
tmpfs                     3.6G         0      3.6G   0% /proc/acpi
tmpfs                    64.0M         0     64.0M   0% /proc/kcore
tmpfs                    64.0M         0     64.0M   0% /proc/keys
tmpfs                    64.0M         0     64.0M   0% /proc/timer_list
tmpfs                    64.0M         0     64.0M   0% /proc/sched_debug
tmpfs                     3.6G         0      3.6G   0% /proc/scsi
tmpfs                     3.6G         0      3.6G   0% /sys/firmware
  • 测试存储空间读写
# 写入 1GB 的数据
$ kubectl exec test-pod-longhorn -- dd if=/dev/zero of=/mnt/test-disk.img bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1000.0MB) copied, 5.670424 seconds, 176.4MB/s

# 查看结果
$ kubectl exec test-pod-longhorn -- ls -lh /mnt/
[root@ksp-control-1 srv]# kubectl exec test-pod-longhorn -- ls -lh /mnt/
total 1000M
-rw-r--r--    1 root     root           0 Jul 17 01:03 SUCCESS
drwx------    2 root     root       16.0K Jul 17 01:03 lost+found
-rw-r--r--    1 root     root     1000.0M Jul 17 01:04 test-disk.img

# 测试超限（再写入 1GB 数据）
$ kubectl exec test-pod-longhorn -- dd if=/dev/zero of=/mnt/test-disk2.img bs=1M count=1000
dd: /mnt/test-disk2.img: No space left on device
command terminated with exit code 1

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

4.3 查看底层存储信息

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

$ ls -lR /longhorn/
/longhorn/:
total 4
-rw-r--r-- 1 root root 51 Jul 16 11:18 longhorn-disk.cfg
drwxr-xr-x 3 root root 63 Jul 17 01:02 replicas

/longhorn/replicas:
total 0
drwx------ 2 root root 108 Jul 17 01:03 pvc-d5a7fc28-2e4c-4f9d-b4d7-7cb7ca5a7ea7-3a7acff9

/longhorn/replicas/pvc-d5a7fc28-2e4c-4f9d-b4d7-7cb7ca5a7ea7-3a7acff9:
total 2075652
-rw------- 1 root root       4096 Jul 17 01:06 revision.counter
-rw-r--r-- 1 root root 2147483648 Jul 17 01:06 volume-head-000.img
-rw-r--r-- 1 root root        126 Jul 17 01:02 volume-head-000.img.meta
-rw-r--r-- 1 root root        142 Jul 17 01:03 volume.meta

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

4.4 清理测试资源

  • 清理测试 Pod、PVC
kubectl delete -f test-pod-longhorn.yaml -f test-pvc-longhorn.yaml
  • 在存储服务器（ ksp-storage-1 节点）查看数据目录
$ ls -lR /longhorn/replicas/
/longhorn/replicas/:
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 发布！

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/1954899.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

使用Pyqt5基于yolo目标识别算法实现车辆和行人识别

使用Pyqt5基于yolo目标识别算法实现车辆和行人识别

文章目录 一、视频演示二、实现的功能2.1、逻辑流程框架 三、Pyqt介绍3.1、PyQt5软件安装3.2PyQt5-tools软件安装 四、yolo目标识别算法介绍4.1、YoloV8环境安装 五、环境搭建六、运行跑一下七、代码 一、视频演示 yolo目标识别算法实现车辆识别与行人识别 二、实现的功能 摄像…
阅读更多...
【Linux C | 网络编程】进程池大文件传输的实现详解（三）

【Linux C | 网络编程】进程池大文件传输的实现详解（三）

上一篇实现了进程池的小文件传输&#xff0c;使用自定义的协议&#xff0c;数据长度数据本身&#xff0c;类似小火车的形式&#xff0c;可以很好的解决TCP“粘包”的问题。 【Linux C | 网络编程】进程池小文件传输的实现详解&#xff08;二&#xff09; 当文件的内容大小少于…
阅读更多...
个人博客搭建——Halo

个人博客搭建——Halo

1 概述 Halo是一个开源的博客系统&#xff0c;有较多的插件支持&#xff0c;用下来感觉还可以 2 搭建流程 2.1 配置系统环境 需要以下系统环境 1、Ubuntu系统 2、Mysql&#xff08;替换原生数据库&#xff09; 2.2 下载jar包 这里选择的是jar包部署 下载路径&#xff1a;…
阅读更多...
通过nvm在Win7系统中安装v16.17.0及以上版本的nodejs

通过nvm在Win7系统中安装v16.17.0及以上版本的nodejs

操作步骤 1.通过nvm安装node - v16.17.0 nvm install 16.17.0若您尚未安装nvm&#xff0c;请参阅&#xff1a;https://blog.csdn.net/weixin_45687201/article/details/135636453 由于我已经安装过了&#xff0c;这里贴图&#xff1a; 2.配置win7环境变量 1.找到node 16.17.…
阅读更多...
【AI大模型】Prompt 提示词工程使用详解

【AI大模型】Prompt 提示词工程使用详解

目录 一、前言 二、Prompt 提示词工程介绍 2.1 Prompt提示词工程是什么 2.1.1 Prompt 构成要素 2.2 Prompt 提示词工程有什么作用 2.2.1 Prompt 提示词工程使用场景 2.3 为什么要学习Prompt 提示词工程 三、Prompt 提示词工程元素构成与操作实践 3.1 前置准备 3.2 Pro…
阅读更多...
“科技创新‘圳’在变革”2025深圳电子展

“科技创新‘圳’在变革”2025深圳电子展

电子产业作为现代社会的核心驱动力之一&#xff0c;正以前所未有的速度发展。在这样的背景下&#xff0c;深圳作为中国的经济特区和创新高地&#xff0c;又一次迎来了备受瞩目的盛会——2025深圳电子展览会。本次展览会定于2025年4月9日至11日&#xff0c;在深圳会展中心&#…
阅读更多...
vue路由跳转时改变路由参数组件不渲染问题【已解决】

vue路由跳转时改变路由参数组件不渲染问题【已解决】

效果展示 解决 router路由为了组件复用&#xff0c;防止组件的频繁销毁与创建&#xff0c;在遇到跳转的路由不一致才会进行重新渲染&#xff0c;路径参数变了他是不会管的&#xff0c;只会改变this.$route对象而已 就这个东西/:xxx 我们可以写一个watch监视this.$route对象。…
阅读更多...
virtualbox ubuntu扩充磁盘大小

virtualbox ubuntu扩充磁盘大小

首先在虚拟存储管理里面修改磁盘大小 然后安装gparted sudo gparted 打开管理工具 选中要调整的区域右键选择调整区域大小 拖动上述位置就可以实现扩容。完成后点击应用 然后重启虚拟机即可。
阅读更多...
永结无间Ⅱ--大语言模型最终会代替人类吗？

永结无间Ⅱ--大语言模型最终会代替人类吗？

涵盖的主题 当前大语言模型的缺点为何大语言模型 (LLM) 缺乏常识&#xff1f;自主智能的架构相信超级智能的人的说法源于对智力误解的错误推理环境对个人智力有严格限制智力是外在的&#xff0c;存在于文明发展之中无论人工智能变得多么聪明&#xff0c;它都无法扩展递归式自我…
阅读更多...
可达2951题 数位拆分

可达2951题 数位拆分

题目&#xff1a; 思路&#xff1a;从二进制的角度&#xff0c;从0到30位每一位来判断求和&#xff0c;开一个新的数组统计第i位是0和1的个数&#xff0c;a[i]放到0&#xff5e;30位的每一位上&#xff0c;然后将a&#xff3b;i&#xff3d;在第位上为0数量乘以2的次方。 代…
阅读更多...
编译之舞：C/C++ 与 GCC 的协作曲

编译之舞：C/C++ 与 GCC 的协作曲

文章目录 一、C/C 编译过程的四个阶段1. 编译之舞的台前幕后2. 舞台布景的准备——预处理3. 舞者的基本训练——编译4. 编舞师的细节调整——汇编5. 合奏的和谐统一——链接 二、舞姿的动作细——编译详细模式三、幕后——GCC 的各种选项&#xff08;Overall Option&#xff09…
阅读更多...
Milvus Lite, Milvus Cloud, Standalone, 与 Distributed：组件功能关系深度解析

Milvus Lite, Milvus Cloud, Standalone, 与 Distributed：组件功能关系深度解析

在大数据时代，高效、灵活的向量搜索解决方案成为了许多企业和研究机构不可或缺的技术支撑。Milvus，作为一款开源的向量数据库，凭借其卓越的性能、可扩展性和易用性，在众多向量搜索引擎中脱颖而出。Milvus 提供了 Lite、Cloud、Standalone、Distributed 四种部署模式，每种模…
阅读更多...
55. 跳跃游戏【 力扣(LeetCode) 】

55. 跳跃游戏【 力扣(LeetCode) 】

一、题目描述 给你一个非负整数数组 nums &#xff0c;你最初位于数组的 第一个下标 。数组中的每个元素代表你在该位置可以跳跃的最大长度。 判断你是否能够到达最后一个下标&#xff0c;如果可以&#xff0c;返回 true &#xff1b;否则&#xff0c;返回 false 。 二、测试用…
阅读更多...
Python学习笔记44：游戏篇之外星人入侵(五)

Python学习笔记44：游戏篇之外星人入侵(五)

前言 上一篇文章中&#xff0c;我们成功的设置好了游戏窗口的背景颜色&#xff0c;并且在窗口底部中间位置将飞船加载出来了。 今天&#xff0c;我们将通过代码让飞船移动。 移动飞船 想要移动飞船&#xff0c;先要明白飞船位置变化的本质是什么。 通过上一篇文章&#xff0…
阅读更多...
STM32的GPIO输入输出方式设置示例

STM32的GPIO输入输出方式设置示例

1、GPIO口做基本的输入/输出口使用时&#xff0c;输入有上拉输入、下拉输入、浮空输入&#xff08;既无上拉电阻也无下拉电阻&#xff09;3种输入方式&#xff1b;输出有开漏输出、推挽输出2种输出方式。 2、示例 &#xff08;1&#xff09;示例1&#xff1a;GPIO做输出的设置…
阅读更多...
【机器学习】pytorch 常用函数解析

【机器学习】pytorch 常用函数解析

目录 一、基本函数介绍 1.1 nn.Module 类 1.2 nn.Embedding 1.3 nn.LSTM 1.4 nn.Linear 1.5 nn.CrossEntropyLoss 1.6 torch.save 1.7 torch.load 1.8 nn.functional 1.9 nn.functional.softmax 本文主要对 pytorch 中用到的函数进行介绍&#xff0c;本文会不断更新~…
阅读更多...
【Redis进阶】主从复制

【Redis进阶】主从复制

1. 主从结构引入 在分布式系统中&#xff0c;涉及到一个严重问题&#xff1a;单点问题 即如果某个服务器程序只有一个节点&#xff08;单台机器提供服务&#xff09;&#xff0c;就会出现以下两个问题&#xff1a; 可用性问题&#xff0c;如果这台机器挂了&#xff0c;意味着…
阅读更多...
Github 2024-07-27开源项目日报 Top10

Github 2024-07-27开源项目日报 Top10

根据Github Trendings的统计，今日(2024-07-27统计)共有10个项目上榜。根据开发语言中项目的数量，汇总情况如下： 开发语言项目数量非开发语言项目2C++项目2C项目2TypeScript项目1JavaScript项目1Java项目1Python项目1C#项目1免费编程学习平台：freeCodeCamp.org 创建周期：33…
阅读更多...
jQuery入门（一）

jQuery入门（一）

一、JQuery介绍 - jQuery 是一个 JavaScript 库。 - 所谓的库&#xff0c;就是一个 JS 文件&#xff0c;里面封装了很多预定义的函数&#xff0c;比如获取元素&#xff0c;执行隐藏、移动等&#xff0c;目的就 是在使用时直接调用&#xff0c;不 需要再重复定义&#xff0c;这…
阅读更多...
iPhone 在 App Store 中推出的 PC 模拟器 UTM SE

iPhone 在 App Store 中推出的 PC 模拟器 UTM SE

PC 模拟器是什么&#xff1f;PC 模拟器是一种软件工具&#xff0c;它模拟不同硬件或操作系统环境&#xff0c;使得用户可以在一台 PC 上运行其他平台的应用程序或操作系统。通过 PC 模拟器&#xff0c;用户可以在 Windows 电脑上体验 Android 应用、在 Mac 电脑上运行 Windows …
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023