共计 7480 个字符,预计需要花费 19 分钟才能阅读完成。
Block Devices(块存储)
在 Rook 中,块存储有两种存储类型:正本存储和纠删码存储。这两种存储类型都能够在 Kubernetes 集群中应用,能够通过在 CephBlockPool 中指定不同的存储类别来实现。
- 「正本存储:」 是一种基于正本的存储形式,其中数据被复制到多个节点上,以进步数据的可靠性和可用性。在正本存储中,数据被复制到指定数量的节点,当其中任何一个节点呈现故障时,零碎依然能够从其它节点读取数据,从而保障了数据的可靠性和可用性。
- 「纠删码存储:」 是一种基于纠删码的存储形式,其中数据被编码为多个数据块,并在不同的节点上存储这些数据块的编码片段。在纠删码存储中,数据被编码为多个数据块,并依据指定的参数对这些数据块进行编码。编码后的数据块被扩散存储到不同的节点上,当某个节点呈现故障时,零碎能够应用存储在其它节点上的数据块编码片段来复原数据。纠删码存储在数据可靠性和存储效率方面具备劣势,但它通常须要更多的 CPU 和网络资源来执行编码和解码操作。
如何抉择
在生产环境中抉择 Rook 中的正本存储或纠删码存储须要思考多个因素,包含数据的重要性、可用性要求、存储老本和零碎性能等。
- 正本存储提供了简略、易于治理的数据冗余解决方案,通过复制多个数据正本到不同的节点上来进步数据的可靠性和可用性。在正本存储中,数据的每个正本都能够间接读取和写入,因而能够提供较低的读写提早和较高的吞吐量。
- 纠删码存储通过对数据进行编码和分片,将数据的冗余信息散布到不同的节点上,以进步数据的可靠性和可用性。纠删码存储通常须要更少的存储空间和更低的存储老本,因为它只须要存储数据的冗余分片而不是残缺的正本。然而,在读取和写入数据时,须要对多个节点进行通信和协调,因而可能会带来更高的读写提早和较低的吞吐量,而且在产生节点故障时,复原数据的工夫也可能会更长
在抉择 Rook 中的正本存储或纠删码存储时,须要思考数据的重要性和可用性要求,以及存储老本和零碎性能等因素。如果数据的重要性较高,可用性要求较高,并且存储老本较高,能够抉择正本存储;如果数据的可用性要求较高,存储老本较低,并且能够容忍较高的读写提早和较低的吞吐量,能够抉择纠删码存储。在抉择存储计划时,还须要思考硬件资源和网络带宽等因素,以确保所选计划能够满足零碎性能和可用性要求。
实战
- 创立 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 驱动程序和节点挂载器之间的身份验证和受权。
- 开始创立
kubectl create -f storageclass.yaml
- 创立后验证
# 查看 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 上,以提供所需的长久化存储资源。
- 提前创立一个 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。
- 创立一个利用 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
- 验证是否挂载胜利
# 查看定义的 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
- 卸载块存储
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 块存储。否则,可能会导致未清理的资源或数据遗留在集群中。
本文转载于 WX 公众号:不背锅运维(喜爱的盆友关注咱们):https://mp.weixin.qq.com/s/6PYW3yQvn1v0CRS7iOUHDA