探索 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-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-nodeportnamespace: longhorn-systemlabels:app: longhorn-ui
spec:ports:- name: httpprotocol: TCPport: 80targetPort: httpnodePort: 32222selector:app: longhorn-uiclusterIP: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: longhornaccessModes:- ReadWriteManyresources: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-longhornimage: busybox:stablecommand:- "/bin/sh"args:- "-c"- "touch /mnt/SUCCESS && sleep 3600"volumeMounts:- name: longhorn-pvcmountPath: "/mnt"restartPolicy: "Never"nodeSelector:kubernetes.io/storage: longhornvolumes:- name: longhorn-pvcpersistentVolumeClaim: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-7cb7ca5a7ea71.9G         0      1.9G   0% /mnt
/dev/mapper/openeuler-root34.2G      2.3G     30.2G   7% /etc/hosts
/dev/mapper/openeuler-root34.2G      2.3G     30.2G   7% /dev/termination-log
/dev/mapper/data-lvdata99.9G      4.7G     95.2G   5% /etc/hostname
/dev/mapper/data-lvdata99.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.mzph.cn/web/50338.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

因为媳妇的一句话,我做了一个AI画图软件

因为媳妇的一句话&#xff0c;我做了一个AI画图软件 T恤的配图 前些天媳妇参加了一个创业比赛&#xff0c;其中一个比赛任务是参赛成员需要穿主题队服&#xff0c;队服的图案完全需要自己设计&#xff0c;需要独一无二还得漂亮。 问我&#xff1a;“能不能用AI做一张图&#…

Python酷库之旅-第三方库Pandas(052)

目录 一、用法精讲 191、pandas.Series.drop方法 191-1、语法 191-2、参数 191-3、功能 191-4、返回值 191-5、说明 191-6、用法 191-6-1、数据准备 191-6-2、代码示例 191-6-3、结果输出 192、pandas.Series.droplevel方法 192-1、语法 192-2、参数 192-3、功能…

C# 介绍

文章目录 一. 一个简单的helloworld二. 程序结构三. 类型和变量四. 表达式1. f(x)2. []3. typeof4. default5. new6. checked和unchecked7. sizeof8. 移位9. is和as10. null合并 五. 语句六. 类和对象1. 可访问性2. 类型参数3. 基类和派生类4. 字段5. 方法6. 参数7. 扩展方法&a…

53.综合实验:UART接收图像、写入RAM、通过TFT显示

&#xff08;1&#xff09;设计定义&#xff1a;UART_RX模块接收数据&#xff0c;通过写入逻辑写入RAM存储器中&#xff0c;然后通过读取逻辑&#xff0c;从RAM中读出数据&#xff0c;发送给TFT显示屏。 &#xff08;2&#xff09;FPGA逻辑资源有限&#xff0c;因此设置128 * 1…

新生报到系统2024((代码+论文+ppt)

下载在最后 技术栈: ssmmysqljsp 展示: 下载地址: CSDN现在上传有问题,有兴趣的朋友先收藏.正常了贴上下载地址 备注:

docker安装部署elasticsearch7.15.2

docker安装部署elasticsearch7.15.2 1.拉取es镜像 docker pull docker.elastic.co/elasticsearch/elasticsearch:7.15.2如果不想下载或者镜像拉去太慢可以直接下载文章上面的镜像压缩包 使用镜像解压命令 docker load -i elasticsearch-7-15-2.tar如下图所示就表示镜像解压成…

Qt+OpenCascade开发笔记(二):windows开发环境搭建(二):Qt引入occ库,搭建基础工程模板Demo和发布Demo

若该文为原创文章&#xff0c;转载请注明原文出处 本文章博客地址&#xff1a;https://hpzwl.blog.csdn.net/article/details/140763014 长沙红胖子Qt&#xff08;长沙创微智科&#xff09;博文大全&#xff1a;开发技术集合&#xff08;包含Qt实用技术、树莓派、三维、OpenCV…

51单片机嵌入式开发:19、STC89C52R控制LCD1602码表+数码管+后台数显(串口)

STC89C52R控制LCD1602码表数码管后台数显&#xff08;串口&#xff09; 1 概述1.1 项目概述1.2 项目组成部分1.3 功能描述 2 开发环境2.1 支持设备2.2 硬件电路 3 软件代码工程4 演示4.1 Proteus仿真4.2 实物演示 5 总结 1 概述 1.1 项目概述 本项目旨在利用STC89C52R单片机实…

后端笔记(1)--javaweb简介

1.JavaWeb简介 ​ *用Java技术来解决相关web互联网领域的技术栈 1.网页&#xff1a;展现数据 2.数据库&#xff1a;存储和管理数据 3.JavaWeb程序&#xff1a;逻辑处理 2.mysql 1.初始化Mysql mysqld --initialized-insecure2.注册Mysql服务 mysqld -install3.启动Mysql…

USB3.0的等长要求到底是多少?

USB2.0与USB3.0接口的PCB布局布线要求PCB资源PCB联盟网 - Powered by Discuz! (pcbbar.com) 90欧姆阻抗&#xff0c;走差分线&#xff1a; 重点来了&#xff1a;

第十九届全国大学生智能汽车竞赛地平线创意组在武汉理工大学隆重开幕

7月27日上午&#xff0c;第十九届全国大学生智能汽车竞赛地平线创意组智慧医疗赛道全国选拔赛开幕式隆重举行&#xff0c;大赛由中国自动化学会、第十九届全国大学生智能汽车竞赛组织委员会主办&#xff0c;武汉理工大学、地平线、古月居承办。首年即吸引来自全国各地280支队伍…

国内乳品领军企业『君乐宝』SRM一期项目成功上线,企企通助力企业采购数字化再升级,二期项目正式启航!

近日&#xff0c;企企通为君乐宝乳业集团&#xff08;以下简称“君乐宝”&#xff09;打造的采购供应链管理系统一期项目成功上线运行&#xff0c;基于双方的信任基础与协作模式将再次携手深化合作&#xff0c;构建全品类、全流程、全场景、全模式的采购数字化管理闭环&#xf…

如何为 5G 小型基站部署选择振荡器

5G 网络频谱频率更高、覆盖范围更短&#xff0c;因此比前几代网络密度更高。超高速 5G 回程 (mmWave) 在很大程度上依赖于小型基站&#xff0c;不仅是为了覆盖范围&#xff0c;也是为了速度。除此之外&#xff0c;O-RAN 联盟等举措为 RAN 生态系统提供了更多选择&#xff0c;但…

Scrapy + Django爬虫可视化项目实战(一)

目录 一、项目介绍 (一) 项目背景 (二) 项目介绍 二、系统实现 (一) 爬虫 1. 实现步骤 一、爬取字段 二、分析页面 三、具体实现 2. 爬虫结果 系列文章 Python升级打怪—Django入门 Python升级打怪—Scrapy零基础小白入门 实现技术 ScrapyDjangoEcharts 一、项目…

CSS(五)——CSS Fonts(字体)

CSS 字体 CSS字体属性定义字体&#xff0c;加粗&#xff0c;大小&#xff0c;文字样式。 CSS字型 在CSS中&#xff0c;有两种类型的字体系列名称&#xff1a; 通用字体系列 - 拥有相似外观的字体系统组合&#xff08;如 "Serif" 或 "Monospace"&#x…

黑马程序员2024最新SpringCloud微服务开发与实战 个人学习心得、踩坑、与bug记录Day5 全网最快最全

你好,我是Qiuner. 为帮助别人少走弯路和记录自己编程学习过程而写博客 这是我的 github https://github.com/Qiuner ⭐️ gitee https://gitee.com/Qiuner &#x1f339; 如果本篇文章帮到了你 不妨点个赞吧~ 我会很高兴的 &#x1f604; (^ ~ ^) 想看更多 那就点个关注吧 我会…

hadoop学习(一)

一.hadoop概述 1.1hadoop优势 1&#xff09;高可靠性&#xff1a;Hadoop底层维护多个数据副本&#xff0c;即使Hadoop某个计算元素或存储出现故障&#xff0c;也不会导致数据的丢失。 2&#xff09;高扩展性&#xff1a;在集群间分配任务数据&#xff0c;可方便扩展数以千计…

SPSS个人版是什么软件

SPSS是一款数据统计、分析软件&#xff0c;它由IBM公司出品&#xff0c;这款软件平台提供了文本分析、大量的机器学习算法、数据分析模型、高级统计分析功能等&#xff0c;软件易学且功能非常强大&#xff0c;可以使用SPSS制作图表&#xff0c;例如柱状、饼状、折线等图表&…

【Drools】(一)基于业务需求动态生成 DRT 规则模板:事实与动作定义详解

&#xff08;一&#xff09;基于业务需求动态生成 DRT 规则模板&#xff1a;事实与动作定义详解 背景 在业务规则管理中&#xff0c;DRT 文件&#xff08;Drools Rule Template&#xff09;用于定义和重用规则模板&#xff0c;这些模板可以动态地根据实际业务需求进行填充和生…

Android 10.0 Launcher 启动流程

在前面SystemUI启动流程中说到&#xff0c;在SystemServer中会去启动各种系统服务&#xff0c;这里的launcher也是启动的其中一个服务ActivityManagerService去启动的。在android10之前&#xff0c;系统四大组件的启动都是在ActivityManagerService中&#xff0c;在android10中…