- ubuntu12.04环境下使用kvm ioctl接口实现最简单的虚拟机
- Ubuntu 通过无线网络安装Ubuntu Server启动系统后连接无线网络的方法
- 在Ubuntu上搭建网桥的方法
- ubuntu 虚拟机上网方式及相关配置详解
CFSDN坚持开源创造价值,我们致力于搭建一个资源共享平台,让每一个IT人在这里找到属于你的精彩世界.
这篇CFSDN的博客文章云原生 Kubernetes 分布式存储平台 Longhorn 初体验由作者收集整理,如果你对这篇文章有兴趣,记得点赞哟.
前面我们学习了本地存储、NFS共享存储,除了这些存储类型之外,还有一个块存储,同样为 Kubernetes 提供块存储的方案有很多,比如 Ceph RBD,今天我们为大家介绍的是 Rancher 开源的一款 Kubernetes 的云原生分布式块存储方案 - Longhorn,Longhorn 是一个轻量级且功能强大的云原生 Kubernetes 分布式存储平台,可以在任意基础设施上运行,Longhorn 还可以与 Rancher 结合使用,将帮助你在 Kubernetes 环境中轻松、快速和可靠地部署高可用性持久化块存储.
使用 Longhorn,可以:
Longhorn 还带有独立的 UI,可以使用 Helm、kubectl 或 Rancher 应用程序目录进行安装.
Longhorn 为每个卷创建一个专用的存储控制器,并在多个节点上存储的多个副本之间同步复制该卷。Longhorn 在整体上分为两层:数据平面和控制平面,Longhorn Engine 是存储控制器,对应数据平面,Longhorn Manager 对应控制平面.
Longhorn Manager 会以 DaemonSet 的形式在 Longhorn 集群中的每个节点上运行,它负责在 Kubernetes 集群中创建和管理卷,并处理来自 UI 或 Kubernetes 卷插件的 API 调用,它是遵循 Kubernetes 控制器模式.
Longhorn Manager 通过与 Kubernetes APIServer 通信来创建新的 Longhorn volume CRD,然后 Longhorn Manager 会一直 Watch APIServer 的响应,当它看到发现创建了一个新的 Longhorn volume CRD 时,Longhorn Manager 就会去创建一个新的对应卷。当 Longhorn Manager 被要求创建一个卷时,它会在卷所连接的节点上创建一个 Longhorn Engine 实例,并在每个将放置副本的节点上创建一个副本,副本应放置在不同的主机上以确保最大可用性。副本的多条数据路径确保了 Longhorn 卷的高可用性,即使某个副本或引擎出现问题,也不会影响所有副本或 Pod 对卷的访问.
Longhorn Engine 始终与使用 Longhorn 卷的 Pod 在同一节点中运行,它在存储在多个节点上的多个副本之间同步复制卷.
如下图所示,描述了 Longhorn 卷、Longhorn Engine、副本实例和磁盘之间的读/写数据流
卷、Longhorn Engine、副本实例和磁盘之间的读/写数据流 。
注意: 图中的 Engine 并非是单独的一个 Pod,而是每一个 Volume 会对应一个 golang exec 出来的 Linux 进程 。
在 Longhorn 中,每个 Engine 只需要服务一个卷,简化了存储控制器的设计,由于控制器软件的故障域与单个卷隔离,因此控制器崩溃只会影响一个卷。由于 Longhorn Engine 足够简单和轻便,因此我们可以创建多达 100000 个独立的 Engine,Kubernetes 去调度这些独立的 Engine,从一组共享的磁盘中提取资源,并与 Longhorn 合作形成一个弹性的分布式块存储系统.
因为每个卷都有自己的控制器,所以每个卷的控制器和副本实例也可以升级,而不会导致 IO 操作明显中断。Longhorn 可以创建一个长时间运行的 job 任务来协调所有卷的升级,而不会中断系统的运行.
Longhorn 是通过 CSI 驱动在 Kubernetes 中管理的,CSI 驱动通过调用 Longhorn 来创建卷,为 Kubernetes 工作负载创建持久性数据,CSI 插件可以让我们创建、删除、附加、分离、挂载卷,并对卷进行快照操作,Kubernetes 集群内部使用 CSI 接口与Longhorn CSI 驱动进行通信,而 Longhorn CSI 驱动是通过使用 Longhorn API 与 Longhorn Manager 进行通信.
此外 Longhorn 还提供一个 UI 界面程序,通过 Longhorn API 与 Longhorn Manager 进行交互,通过 Longhorn UI 可以管理快照、备份、节点和磁盘等,此外,集群工作节点的空间使用情况还可以通过 Longhorn UI 查看.
要在 Kubernetes 集群上安装 Longhorn,需要集群的每个节点都必须满足以下要求:
Longhorn workloads 必须能够以 root 身份运行才能正确部署和操作 Longhorn.
为了验证这些环境要求,Longhorn 官方提供了一个脚本来帮助我们进行检查,执行该脚本需要在本地安装 jq 工具,执行下面的命令即可运行脚本:
➜ curl -sSfL https://raw.githubusercontent.com/longhorn/longhorn/v1.2.3/scripts/environment_check.sh | bash daemonset.apps/longhorn-environment-check created waiting for pods to become ready (0/2) waiting for pods to become ready (0/2) all pods ready (2/2) MountPropagation is enabled! cleaning up... daemonset.apps "longhorn-environment-check" deleted clean up complete
如果没有检查通过会给出相关的提示信息.
要安装 open-iscsi,可以直接使用下面的命令即可:
# apt-get install open-iscsi # Debian 和 Ubuntu 系统命令 ➜ yum install -y iscsi-initiator-utils
Longhorn 官方还为我们还提供了一个 iscsi 安装程序,可以更轻松地自动安装 open-iscsi:
➜ kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v1.2.3/deploy/prerequisite/longhorn-iscsi-installation.yaml
部署完成后,运行以下命令来检查安装程序的 pod 状态:
➜ kubectl get pod | grep longhorn-iscsi-installation longhorn-iscsi-installation-49hd7 1/1 Running 0 21m longhorn-iscsi-installation-pzb7r 1/1 Running 0 39m
也可以通过以下命令查看日志,查看安装结果:
➜ kubectl logs longhorn-iscsi-installation-pzb7r -c iscsi-installation ... Installed: iscsi-initiator-utils.x86_64 0:6.2.0.874-7.amzn2 Dependency Installed: iscsi-initiator-utils-iscsiuio.x86_64 0:6.2.0.874-7.amzn2 Complete! Created symlink from /etc/systemd/system/multi-user.target.wants/iscsid.service to /usr/lib/systemd/system/iscsid.service. iscsi install successfully
同样要安装 NFSv4 客户端,可以直接使用下面的命令一键安装:
# apt-get install nfs-common # Debian 和 Ubuntu 系统命令 ➜ yum install nfs-utils
同样 Longhorn 官方也提供了一个 nfs 客户端安装程序,可以更轻松地自动安装 nfs-client:
➜ kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v1.2.3/deploy/prerequisite/longhorn-nfs-installation.yaml
部署完成后,运行以下命令来检查安装程序的 pod 状态:
➜ kubectl get pod | grep longhorn-nfs-installation NAME READY STATUS RESTARTS AGE longhorn-nfs-installation-t2v9v 1/1 Running 0 143m longhorn-nfs-installation-7nphm 1/1 Running 0 143m
也可以通过以下命令查看日志,查看安装结果:
➜ kubectl logs longhorn-nfs-installation-t2v9v -c nfs-installation ... nfs install successfully
相关依赖环境准备好过后就可以开始安装 Longhorn 了.
官方支持使用 Rancher Catalog 应用、kubectl 与 helm 三种方式来进行安装,同样这里我们选择使用 helm 进行安装.
首先添加 longhorn 的 chart 仓库:
➜ helm repo add longhorn https://charts.longhorn.io ➜ helm repo update
然后可以根据自己的实际场景定制 values 文件,可以通过下面的命令获取默认的 values 文件:
➜ curl -Lo values.yaml https://raw.githubusercontent.com/longhorn/charts/master/charts/longhorn/values.yaml
然后可以修改 values 文件中的配置,longhorn 推荐单独挂盘作为存储使用,这里作为测试直接使用默认的 /var/lib/longhorn 目录.
如下所示默认配置的示例片段:
defaultSettings: backupTarget: s3://backupbucket@us-east-1/backupstore backupTargetCredentialSecret: minio-secret createDefaultDiskLabeledNodes: true defaultDataPath: /var/lib/longhorn-example/ replicaSoftAntiAffinity: false storageOverProvisioningPercentage: 600 storageMinimalAvailablePercentage: 15 upgradeChecker: false defaultReplicaCount: 2 defaultDataLocality: disabled guaranteedEngineCPU: defaultLonghornStaticStorageClass: longhorn-static-example backupstorePollInterval: 500 taintToleration: key1=value1:NoSchedule; key2:NoExecute systemManagedComponentsNodeSelector: "label-key1:label-value1" priority-class: high-priority autoSalvage: false disableSchedulingOnCordonedNode: false replicaZoneSoftAntiAffinity: false volumeAttachmentRecoveryPolicy: never nodeDownPodDeletionPolicy: do-nothing mkfsExt4Parameters: -O ^64bit,^metadata_csum guaranteed-engine-manager-cpu: 15 guaranteed-replica-manager-cpu: 15 ingress: # 开启ingress enabled: true ingressClassName: nginx # 配置 ingressclass host: longhorn.k8s.local annotations: # 添加annotations nginx.ingress.kubernetes.io/proxy-body-size: 10000m enablePSP: false
然后执行下面的命令一键安装 Longhorn:
➜ helm upgrade --install longhorn longhorn/longhorn --namespace longhorn-system --create-namespace -f values.yaml NAME: longhorn LAST DEPLOYED: Sun Feb 20 16:14:05 2022 NAMESPACE: longhorn-system STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: Longhorn is now installed on the cluster! Please wait a few minutes for other Longhorn components such as CSI deployments, Engine Images, and Instance Managers to be initialized. Visit our documentation at https://longhorn.io/docs/
部署后可以查看 Pod 的运行状态来确保安装正确:
➜ kubectl get pods -n longhorn-system NAME READY STATUS RESTARTS AGE csi-attacher-5f46994f7-fqntq 1/1 Running 0 33s csi-attacher-5f46994f7-ltxg8 1/1 Running 0 36m csi-attacher-5f46994f7-vw75d 1/1 Running 0 36m csi-provisioner-6ccbfbf86f-bvc99 1/1 Running 0 33s csi-provisioner-6ccbfbf86f-k46hn 1/1 Running 0 36m csi-provisioner-6ccbfbf86f-lxm8h 1/1 Running 0 36m csi-resizer-6dd8bd4c97-52gmm 1/1 Running 0 35m csi-resizer-6dd8bd4c97-9btj6 1/1 Running 0 3s csi-resizer-6dd8bd4c97-fdjmp 1/1 Running 0 35m csi-snapshotter-86f65d8bc-5mjk2 1/1 Running 0 33s csi-snapshotter-86f65d8bc-5rrfs 1/1 Running 0 35m csi-snapshotter-86f65d8bc-bg6nv 1/1 Running 0 35m engine-image-ei-fa2dfbf0-jrb2d 1/1 Running 0 36m engine-image-ei-fa2dfbf0-m5799 1/1 Running 0 36m instance-manager-e-051171e6 1/1 Running 0 36m instance-manager-e-db94b4b7 1/1 Running 0 24m instance-manager-r-dd84ad5c 1/1 Running 0 36m instance-manager-r-f5eefb8a 1/1 Running 0 24m longhorn-csi-plugin-mljt2 2/2 Running 0 35m longhorn-csi-plugin-rfzcj 2/2 Running 0 24m longhorn-driver-deployer-6db849975f-dh4p4 1/1 Running 0 58m longhorn-manager-bxks6 1/1 Running 0 24m longhorn-manager-tj58k 1/1 Running 0 2m50s longhorn-ui-6f547c964-k56xr 1/1 Running 0 58m
由于上面安装的时候我们添加了 Ingress 支持,所以可以通过配置的域名去访问 Longhorn UI:
➜ kubectl get ingress -n longhorn-system NAME CLASS HOSTS ADDRESS PORTS AGE longhorn-ingress nginx longhorn.k8s.local 192.168.31.31 80 4m11s
这里我们使用的 ingress-nginx 这个控制器,安装完成后在浏览器中直接访问 http://longhorn.k8s.local 即可:
Longhorn UI 界面中展示了当前存储系统的状态,也可以在页面中进行其他相关配置.
此外还会创建一个默认的 StorageClass 对象:
➜ kubectl get sc longhorn NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE longhorn (default) driver.longhorn.io Delete Immediate true 91m ➜ kubectl get sc longhorn -o yaml allowVolumeExpansion: true apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: annotations: ...... storageclass.kubernetes.io/is-default-class: "true" creationTimestamp: "2022-02-20T09:32:51Z" ...... name: longhorn resourceVersion: "4524911" uid: 6066e858-e7ab-4dab-95db-7ff829e6e01b parameters: fromBackup: "" fsType: ext4 numberOfReplicas: "3" staleReplicaTimeout: "30" provisioner: driver.longhorn.io reclaimPolicy: Delete volumeBindingMode: Immediate
下面我们来测试使用 longhorn 提供一个存储卷,由于提供了默认的 StorageClass,所以直接创建 PVC 即可,创建一个如下所示的 PVC:
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: mysql-pvc spec: storageClassName: longhorn accessModes: - ReadWriteOnce resources: requests: storage: 1Gi
然后部署一个 mysql 应用来使用上面的 PVC 进行数据持久化:
apiVersion: apps/v1 kind: Deployment metadata: name: mysql spec: selector: matchLabels: app: mysql strategy: type: Recreate template: metadata: labels: app: mysql spec: containers: - image: mysql:5.6 name: mysql env: - name: MYSQL_ROOT_PASSWORD value: password ports: - containerPort: 3306 name: mysql volumeMounts: - name: data mountPath: /var/lib/mysql volumes: - name: data persistentVolumeClaim: claimName: mysql-pvc
直接创建上面的资源对象:
➜ kubectl get pvc mysql-pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE mysql-pvc Bound pvc-ec17a7e4-7bb4-4456-9380-353db3ed4307 1Gi RWO longhorn 8s ➜ kubectl get pods NAME READY STATUS RESTARTS AGE mysql-6879698bd4-r8cxz 1/1 Running 0 3m10s ➜ kubectl exec -it mysql-6879698bd4-r8cxz -- mysql -uroot -ppassword Warning: Using a password on the command line interface can be insecure. Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 1 Server version: 5.6.51 MySQL Community Server (GPL) Copyright (c) 2000, 2021, Oracle and/or its affiliates. All rights reserved. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> create database longhorn; Query OK, 1 row affected (0.01 sec) mysql>
应用启动成功后我们可以去节点上查看数据来验证是否成功:
➜ ls /var/lib/longhorn/ engine-binaries longhorn-disk.cfg replicas ➜ ls /var/lib/longhorn/replicas/ pvc-ec17a7e4-7bb4-4456-9380-353db3ed4307-c40376c5 ➜ ls /var/lib/longhorn/replicas/pvc-ec17a7e4-7bb4-4456-9380-353db3ed4307-c40376c5 revision.counter volume-head-000.img volume-head-000.img.meta volume.me
需要注意的是 longhorn 是分布式块存储,与分布式文件系统不同,不能超过 pv 设置的存储大小(上例中为1G)。我们在数据库中创建了一个名为 longhorn 的数据库,然后我们重建 Pod 再次查看数据是否依然存在:
➜ kubectl get pods NAME READY STATUS RESTARTS AGE mysql-6879698bd4-s8tfv 1/1 Running 0 6s ➜ kubectl exec -it mysql-6879698bd4-s8tfv -- mysql -uroot -ppassword Warning: Using a password on the command line interface can be insecure. Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 1 Server version: 5.6.51 MySQL Community Server (GPL) Copyright (c) 2000, 2021, Oracle and/or its affiliates. All rights reserved. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> show databases; +---------------------+ | Database | +---------------------+ | information_schema | | longhorn | | #mysql50#lost+found | | mysql | | performance_schema | +---------------------+ 5 rows in set (0.00 sec) mysql>
可以看到前面创建的数据库依然存在,证明我们的数据持久化成功了。在 Longhorn UI 界面中也可以看到数据卷的信息:
关于 Longhorn 的高级特性请关注后续文章.
原文地址:https://mp.weixin.qq.com/s/BmX-kCkvyNzmG77l44bg5g 。
最后此篇关于云原生 Kubernetes 分布式存储平台 Longhorn 初体验的文章就讲到这里了,如果你想了解更多关于云原生 Kubernetes 分布式存储平台 Longhorn 初体验的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。
我正在运行一个辅助角色,并检查 Azure 上托管的存储中是否存在数据。当我将连接字符串用于经典类型的存储时,我的代码可以正常工作,但是当我连接到 V2 Azure 存储时,它会抛出此异常。 “远程服
在我的应用程序的主页上,我正在进行 AJAX 调用以获取应用程序各个部分所需的大量数据。该调用如下所示: var url = "/Taxonomy/GetTaxonomyList/" $.getJSO
大家好,我正在尝试将我的商店导入我的 Vuex Route-Gard。 路由器/auth-guard.js import {store} from '../store' export default
我正在使用 C# 控制台应用程序 (.NET Core 3.1) 从 Azure Blob 存储读取大量图像文件并生成这些图像的缩略图。新图像将保存回 Azure,并将 Blob ID 存储在我们的数
我想将 Mlflow 设置为具有以下组件: 后端存储(本地):在本地使用 SQLite 数据库存储 Mlflow 实体(run_id、params、metrics...) 工件存储(远程):使用 Az
我正在使用 C# 控制台应用程序 (.NET Core 3.1) 从 Azure Blob 存储读取大量图像文件并生成这些图像的缩略图。新图像将保存回 Azure,并将 Blob ID 存储在我们的数
我想将 Mlflow 设置为具有以下组件: 后端存储(本地):在本地使用 SQLite 数据库存储 Mlflow 实体(run_id、params、metrics...) 工件存储(远程):使用 Az
我的 Windows 计算机上的本地文件夹中有一些图像。我想将所有图像上传到同一容器中的同一 blob。 我知道如何使用 Azure Storage SDKs 上传单个文件BlockBlobServi
我尝试发出 GET 请求来获取我的 Azure Blob 存储帐户的帐户详细信息,但每次都显示身份验证失败。谁能判断形成的 header 或签名字符串是否正确或是否存在其他问题? 代码如下: cons
这是用于编写 JSON 的 NeutralinoJS 存储 API。是否可以更新 JSON 文件(推送数据),而不仅仅是用新的 JS 对象覆盖数据。怎么做到的??? // Javascript
我有一个并行阶段设置,想知道是否可以在嵌套阶段之前运行脚本,所以像这样: stage('E2E-PR-CYPRESS') { when { allOf {
我想从命令行而不是从GUI列出VirtualBox VM的详细信息。我对存储细节特别感兴趣。 当我在GUI中单击VM时,可以看到包括存储部分在内的详细信息: 但是到目前为止,我还没有找到通过命令行执行
我有大约 3500 个防洪设施,我想将它们表示为一个网络来确定流动路径(本质上是一个有向图)。我目前正在使用 SqlServer 和 CTE 来递归检查所有节点及其上游组件,只要上游路径没有 fork
谁能告诉我 jquery data() 在哪里存储数据以及何时删除以及如何删除? 如果我用它来存储ajax调用结果,会有性能问题吗? 例如: $("body").data("test", { myDa
有人可以建议如何为 Firebase 存储中的文件设置备份。我能够备份数据库,但不确定如何为 firebase 存储中的文件(我有图像)设置定期备份。 最佳答案 如何进行 Firebase 存储的本地
我最近开始使用 firebase 存储和 firebase 功能。现在我一直在开发从功能到存储的文件上传。 我已经让它工作了(上传完成并且文件出现在存储部分),但是,图像永远保持这样(永远在右侧加载)
我想只允许用户将文件上传到他们自己的存储桶中,最大文件大小为 1MB,仍然允许他们删除文件。我添加了以下内容: match /myusers/{userId}/{allPaths=**} { al
使用生命周期管理策略将容器的内容从冷访问层移动到存档。我正在尝试以下策略,希望它能在一天后将该容器中的所有文件移动到存档层,但事实并非如此在职的。我设置了选择标准“一天未使用后”。 这是 json 代
对于连接到 Azure 存储端点,有 http 和 https 两个选项。 第一。 https 会带来开销,可能是 5%-10%,但我不支付同一个数据中心的费用。 第二。 http 更快,但 Auth
有人可以帮我理解这一点吗?我创建了Virtual Machine in Azure running Windows Server 2012 。我注意到 Azure 自动创建了一个存储帐户。当我进入该存
我是一名优秀的程序员,十分优秀!