开源云原生存储rook:块存储快速入门实战

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
简介: 开源云原生存储rook:块存储快速入门实战

Block Devices(块存储)

在 Rook 中,块存储有两种存储类型:副本存储和纠删码存储。这两种存储类型都可以在 Kubernetes 集群中使用,可以通过在 CephBlockPool 中指定不同的存储类别来实现。

  • 「副本存储:」 是一种基于副本的存储方式,其中数据被复制到多个节点上,以提高数据的可靠性和可用性。在副本存储中,数据被复制到指定数量的节点,当其中任何一个节点出现故障时,系统仍然可以从其它节点读取数据,从而保证了数据的可靠性和可用性。
  • 「纠删码存储:」 是一种基于纠删码的存储方式,其中数据被编码为多个数据块,并在不同的节点上存储这些数据块的编码片段。在纠删码存储中,数据被编码为多个数据块,并根据指定的参数对这些数据块进行编码。编码后的数据块被分散存储到不同的节点上,当某个节点出现故障时,系统可以使用存储在其它节点上的数据块编码片段来恢复数据。纠删码存储在数据可靠性和存储效率方面具有优势,但它通常需要更多的 CPU 和网络资源来执行编码和解码操作。

如何选择

在生产环境中选择 Rook 中的副本存储或纠删码存储需要考虑多个因素,包括数据的重要性、可用性要求、存储成本和系统性能等。

  • 副本存储提供了简单、易于管理的数据冗余解决方案,通过复制多个数据副本到不同的节点上来提高数据的可靠性和可用性。在副本存储中,数据的每个副本都可以直接读取和写入,因此可以提供较低的读写延迟和较高的吞吐量。
  • 纠删码存储通过对数据进行编码和分片,将数据的冗余信息分布到不同的节点上,以提高数据的可靠性和可用性。纠删码存储通常需要更少的存储空间和更低的存储成本,因为它只需要存储数据的冗余分片而不是完整的副本。但是,在读取和写入数据时,需要对多个节点进行通信和协调,因此可能会带来更高的读写延迟和较低的吞吐量,而且在发生节点故障时,恢复数据的时间也可能会更长

在选择 Rook 中的副本存储或纠删码存储时,需要考虑数据的重要性和可用性要求,以及存储成本和系统性能等因素。如果数据的重要性较高,可用性要求较高,并且存储成本较高,可以选择副本存储;如果数据的可用性要求较高,存储成本较低,并且可以容忍较高的读写延迟和较低的吞吐量,可以选择纠删码存储。在选择存储方案时,还需要考虑硬件资源和网络带宽等因素,以确保所选方案可以满足系统性能和可用性要求。

实战

  1. 创建CephBlockPool和StorageClass资源对象
apiVersion: ceph.rook.io/v1
kind: CephBlockPool
metadata:
  name: replicapool
spec:
  failureDomain: host
  replicated:
    size: 3
    requireSafeReplicaSize: true
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: rook-ceph-block
provisioner: rook-ceph.rbd.csi.ceph.com
parameters:
  pool: replicapool
  imageFormat: "2"
  imageFeatures: layering
  csi.storage.k8s.io/provisioner-secret-name: rook-csi-rbd-provisioner
  csi.storage.k8s.io/controller-expand-secret-name: rook-csi-rbd-provisioner
  csi.storage.k8s.io/node-stage-secret-name: rook-csi-rbd-node
  csi.storage.k8s.io/fstype: ext4
allowVolumeExpansion: true
reclaimPolicy: Delete

这是一个用于配置Rook与Ceph集群交互的 Kubernetes StorageClass 的 YAML 文件。 StorageClass 提供了一种抽象方式,允许应用程序请求动态卷(PVC),而不需要事先了解存储资源的底层细节。

在这个 YAML 文件中,有两个 Kubernetes 对象:CephBlockPool 和 StorageClass。

CephBlockPool 是 Rook 中用于管理 Ceph 存储集群的块存储池的 Kubernetes 对象。这个特定的块存储池名为 replicapool,它使用主机故障域进行故障域分离,使用副本存储策略,并将每个对象的副本数量设置为 3,要求所有副本都必须是安全的。每个 CephBlockPool 都对应一个特定的存储后端,用于提供块存储服务。通过创建不同的 CephBlockPool,可以为不同的应用程序提供不同的存储配置和性能要求。

StorageClass 对象指定了使用 Rook Ceph 提供的 CSI 驱动程序创建的存储卷的默认设置。其中 provisioner 指定使用的 CSI 驱动程序名称,pool 指定使用的 Ceph 块存储池名称,imageFormat 指定创建块设备时要使用的映像格式,imageFeatures 指定要启用的块设备特性,例如层次化,csi.storage.k8s.io/provisioner-secret-name,csi.storage.k8s.io/controller-expand-secret-name 和 csi.storage.k8s.io/node-stage-secret-name 分别指定用于身份验证和授权的 Kubernetes 密钥名称,而 allowVolumeExpansion 和 reclaimPolicy 分别定义了动态卷是否允许扩容以及何时删除。

当使用rook搭建好集群后,它已经将用于身份验证和授权所需的 Kubernetes Secret 对象创建好了,使用下面命令可以查看:

[root@k8s-a-master rbd]# kubectl get secret -n rook-ceph
NAME                                TYPE                 DATA   AGE
cluster-peer-token-rook-ceph        kubernetes.io/rook   2      22h
rook-ceph-admin-keyring             kubernetes.io/rook   1      22h
rook-ceph-config                    kubernetes.io/rook   2      22h
rook-ceph-crash-collector-keyring   kubernetes.io/rook   1      22h
rook-ceph-dashboard-password        kubernetes.io/rook   1      22h
rook-ceph-mgr-a-keyring             kubernetes.io/rook   1      22h
rook-ceph-mgr-b-keyring             kubernetes.io/rook   1      22h
rook-ceph-mon                       kubernetes.io/rook   4      22h
rook-ceph-mons-keyring              kubernetes.io/rook   1      22h
rook-csi-cephfs-node                kubernetes.io/rook   2      22h
rook-csi-cephfs-provisioner         kubernetes.io/rook   2      22h
rook-csi-rbd-node                   kubernetes.io/rook   2      22h
rook-csi-rbd-provisioner            kubernetes.io/rook   2      22h
  • provisioner-secret-name 用于 CSI 驱动程序和存储卷创建器之间的身份验证和授权。
  • controller-expand-secret-name 用于 CSI 驱动程序和存储卷扩展控制器之间的身份验证和授权。
  • node-stage-secret-name 用于 CSI 驱动程序和节点挂载器之间的身份验证和授权。
  1. 开始创建
kubectl create -f storageclass.yaml
  1. 创建后验证
# 查看 Rook CephBlockPool 的资源定义
[root@k8s-a-master rbd]# kubectl get crd | grep cephblockpools.ceph.rook.io
cephblockpools.ceph.rook.io                           2023-04-03T08:28:30Z
# 查看存储类
[root@k8s-a-master rbd]# kubectl get storageclass 
NAME              PROVISIONER                  RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
rook-ceph-block   rook-ceph.rbd.csi.ceph.com   Delete          Immediate           true                   18h
[root@k8s-a-master rbd]# 
# 查看 Rook CephBlockPool 的列表
[root@k8s-a-master rbd]# kubectl get cephblockpool -n rook-ceph
NAME          PHASE
replicapool   Ready
# 查看详细信息
kubectl describe cephblockpool replicapool -n rook-ceph

我们已经将Kubernetes使用了Rook Ceph作为存储后端,并创建好了CephBlockPool和StorageClass,接着我们还需要创建一个PersistentVolumeClaim(PVC)对象来请求持久化存储资源。PV将在PVC创建后自动创建。

在创建PVC时,Kubernetes将检查可用的PV列表,寻找一个匹配请求的存储大小、访问模式和StorageClass的PV。如果找到一个可用的PV,则该PV将被绑定到PVC上,并成为PVC的一部分。如果没有可用的PV,则Kubernetes将等待,直到有足够的存储资源可用为止。

在这个过程中,Kubernetes将使用先前创建的StorageClass中指定的CephBlockPool的名称来确定要使用的Ceph存储池。Kubernetes将使用这个信息来自动创建一个对应的PV,该PV将在后台映射到Ceph存储池中。在创建PVC时,PV将自动创建并绑定到PVC上,以提供所需的持久化存储资源。

  1. 提前创建一个PVC
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: rook-ceph-block

在这里,PVC名称为my-pvc,请求5GB的存储空间,并将存储类设置为rook-ceph-block。

  1. 创建一个应用pod
apiVersion: v1
kind: Pod
metadata:
  name: test-nginx-pod
spec:
  containers:
  - name: test-nginx-container
    image: nginx
    volumeMounts:
    - name: storage
      mountPath: /data
  volumes:
  - name: storage
    persistentVolumeClaim:
      claimName: my-pvc
  1. 验证是否挂载成功
# 查看定义的pvc
[root@k8s-a-master ~]# kubectl get pvc
NAME     STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS      AGE
my-pvc   Bound    pvc-76d69972-2a95-44bc-953d-1028b4b69435   5Gi        RWO            rook-ceph-block   74s
# 看看pv有没有自动创建
[root@k8s-a-master ~]# kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM            STORAGECLASS      REASON   AGE
pvc-76d69972-2a95-44bc-953d-1028b4b69435   5Gi        RWO            Delete           Bound    default/my-pvc   rook-ceph-block            77s
# 进入pod查看数据目录
[root@k8s-a-master ~]# kubectl exec -it test-nginx-pod -- bash
root@test-nginx-pod:/# 
root@test-nginx-pod:/# df -h
Filesystem              Size  Used Avail Use% Mounted on
overlay                 250G  4.9G  246G   2% /
tmpfs                    64M     0   64M   0% /dev
tmpfs                   3.9G     0  3.9G   0% /sys/fs/cgroup
/dev/rbd0               4.9G   24K  4.9G   1% /data # 在这里
/dev/mapper/centos-var  250G  4.9G  246G   2% /etc/hosts
shm                      64M     0   64M   0% /dev/shm
tmpfs                   7.7G   12K  7.7G   1% /run/secrets/kubernetes.io/serviceaccount
tmpfs                   3.9G     0  3.9G   0% /proc/acpi
tmpfs                   3.9G     0  3.9G   0% /proc/scsi
tmpfs                   3.9G     0  3.9G   0% /sys/firmware
  1. 卸载块存储
kubectl delete -f pod.yml
kubectl delete -f pvc.yml
kubectl delete -f storageclass.yaml # 这个yaml就是之前我们用于创建的,已经包含了CephBlockPool和StorageClass
# 或者也可以单独执行删除指定的CephBlockPool和StorageClass,不过还是建议storageclass.yaml的方式
kubectl delete cephblockpools.ceph.rook.io replicapool -n rook-ceph
kubectl delete storageclass rook-ceph-block
  • kubectl delete -f pod.yml:这个命令将删除包含 Rook 块存储的 Pod。这将停止 Rook 块存储的所有实例和进程。
  • kubectl delete -f pvc.yml:这个命令将删除 PVC (Persistent Volume Claim) 对象,这个对象定义了要使用的持久化存储资源。这将释放 Rook 块存储占用的存储空间。
  • kubectl delete cephblockpools.ceph.rook.io replicapool -n rook-ceph:这个命令将删除名为 replicapool 的 Rook 块存储池。块存储池是一个逻辑卷,可以在其中创建块设备。删除块存储池将确保不再创建新的块设备。
  • kubectl delete storageclass rook-ceph-block:这个命令将删除名为 rook-ceph-block 的 Rook 存储类。存储类指定了用于存储数据的存储类型和属性。删除存储类将确保不再创建新的 Rook 存储卷。

需要注意的是,这4个命令需要按照指定的顺序执行,以确保完全卸载 Rook 块存储。否则,可能会导致未清理的资源或数据遗留在集群中。

相关实践学习
块存储快速入门
块存储是阿里云为云服务器ECS提供的块设备产品。通过体验挂载数据盘、分区格式化数据盘(Linux)、创建云盘快照、重新初始化数据盘、使用快照回滚云盘和卸载数据盘等功能,带您快速入门块存储。
相关文章
|
1月前
|
人工智能 Cloud Native API
Higress 重磅更新:AI 能力全面开源,云原生能力再升级
Higress 最新的 1.4 版本基于为通义千问,以及多家云上 AGI 厂商客户提供 AI 网关的积累沉淀,开源了大量 AI 原生的网关能力。同时也在 Ingress、可观测、流控等云原生能力上做了全方位升级。
20617 211
|
3月前
|
存储 Kubernetes Cloud Native
【阿里云云原生专栏】云原生容器存储:阿里云CSI与EBS的高效配合策略
【5月更文挑战第29天】阿里云提供云原生容器存储接口(CSI)和弹性块存储(EBS)解决方案,以应对云原生环境中的数据存储挑战。CSI作为Kubernetes的标准接口简化存储管理,而EBS则提供高性能、高可靠性的块存储服务。二者协同实现动态供应、弹性伸缩及数据备份恢复。示例代码展示了在Kubernetes中使用CSI和EBS创建存储卷的过程。
211 3
|
13天前
|
存储 SQL 运维
“震撼发布!PolarDB-X:云原生分布式数据库巨擘,超高并发、海量存储、复杂查询,一网打尽!错过等哭!”
【8月更文挑战第7天】PolarDB-X 是面向超高并发、海量存储和复杂查询场景设计的云原生分布式数据库系统
66 1
|
2月前
|
Kubernetes Cloud Native 开发者
阿里云网络发布 alibaba-load-balancer-controller v1.2.0:开启云原生网关开源新篇章!敬请探索!
**阿里云发布开源版ALB控制器v1.2.0,对齐商业版ALB Ingress Controller v2.10.0。新版本增强了功能特性,提升了用户体验,并提供了最佳实践。功能更新包括自定义标签、QUIC协议支持、转发规则和安全策略等。此外,还引入了ReadinessGate实现滚动升级时的平滑上线和Prestop钩子确保平滑下线。用户可从GitHub获取开源代码,通过Docker Hub拉取镜像,开始使用alibaba-load-balancer-controller v1.2.0。**
189 3
阿里云网络发布 alibaba-load-balancer-controller v1.2.0:开启云原生网关开源新篇章!敬请探索!
|
1月前
|
Kubernetes Cloud Native 微服务
企业级容器部署实战:基于ACK与ALB灵活构建云原生应用架构
这篇内容概述了云原生架构的优势,特别是通过阿里云容器服务Kubernetes版(ACK)和应用负载均衡器(ALB)实现的解决方案。它强调了ACK相对于自建Kubernetes的便利性,包括优化的云服务集成、自动化管理和更强的生态系统支持。文章提供了部署云原生应用的步骤,包括一键部署和手动部署的流程,并指出手动部署更适合有技术背景的用户。作者建议在预算允许的情况下使用ACK,因为它能提供高效、便捷的管理体验。同时,文章也提出了对文档改进的建议,如添加更多技术细节和解释,以帮助用户更好地理解和实施解决方案。最后,展望了ACK未来在智能化、安全性与边缘计算等方面的潜在发展。水文一篇,太忙了,见谅!
|
21天前
|
存储 SQL Cloud Native
云原生数据仓库使用问题之如何将数据设置为冷存储
阿里云AnalyticDB提供了全面的数据导入、查询分析、数据管理、运维监控等功能,并通过扩展功能支持与AI平台集成、跨地域复制与联邦查询等高级应用场景,为企业构建实时、高效、可扩展的数据仓库解决方案。以下是对AnalyticDB产品使用合集的概述,包括数据导入、查询分析、数据管理、运维监控、扩展功能等方面。
|
1月前
|
存储 关系型数据库 分布式数据库
PolarDB,阿里云的云原生分布式数据库,以其存储计算分离架构为核心,解决传统数据库的扩展性问题
【7月更文挑战第3天】PolarDB,阿里云的云原生分布式数据库,以其存储计算分离架构为核心,解决传统数据库的扩展性问题。此架构让存储层专注数据可靠性,计算层专注处理SQL,提升性能并降低运维复杂度。通过RDMA加速通信,多副本确保高可用性。资源可独立扩展,便于成本控制。动态添加计算节点以应对流量高峰,展示了其灵活性。PolarDB的开源促进了数据库技术的持续创新和发展。
249 2
|
2月前
|
存储 Kubernetes 安全
云上攻防-云原生篇&K8s安全&Config泄漏&Etcd存储&Dashboard鉴权&Proxy暴露
云上攻防-云原生篇&K8s安全&Config泄漏&Etcd存储&Dashboard鉴权&Proxy暴露
|
2月前
|
存储 SQL Cloud Native
云原生数据仓库AnalyticDB产品使用合集之热数据存储空间在什么地方查看
阿里云AnalyticDB提供了全面的数据导入、查询分析、数据管理、运维监控等功能,并通过扩展功能支持与AI平台集成、跨地域复制与联邦查询等高级应用场景,为企业构建实时、高效、可扩展的数据仓库解决方案。以下是对AnalyticDB产品使用合集的概述,包括数据导入、查询分析、数据管理、运维监控、扩展功能等方面。
|
3月前
|
自然语言处理 监控 Cloud Native
对话阿里云云原生产品负责人李国强:推进可观测产品与OpenTelemetry开源生态全面融合
阿里云宣布多款可观测产品全面升级,其中,应用实时监控服务 ARMS 在业内率先推进了与 OpenTelemetry 开源生态的全面融合,极大丰富了可观测的数据类型及规模,大幅增强了 ARMS 核心能力。本次阿里云 ARMS 产品全面升级的背景是什么?为什么会产生围绕 OpenTelemetry 进行产品演进的核心策略?在云原生、大模型等新型应用架构类型层出不穷的今天,又将如何为企业解决新的挑战?阿里云云原生应用平台产品负责人李国强接受采访解答了这些疑问,点击本文走进全新升级的阿里云可观测产品。
41946 10

热门文章

最新文章