- Java锁的逻辑(结合对象头和ObjectMonitor)
- 还在用饼状图?来瞧瞧这些炫酷的百分比可视化新图形(附代码实现)⛵
- 自动注册实体类到EntityFrameworkCore上下文,并适配ABP及ABPVNext
- 基于Sklearn机器学习代码实战
随着K8S存储接口逐渐成熟并顺势推出CSI接口规范后,原来“in-tree”(树内)模式的很多存储插件也逐步迁移到了“out-of-tree”(树外)模式的CSI插件上,甚至有些原来支持的存储卷类型都被直接移除了(例如在K8S v1.26上直接移除了 glusterfs 卷类型),查阅了一下K8S官方最新版本的存储相关( Storage/Volumes )的说明,综合最新存储支持情况,我们选择Ceph作为K8S集群的存储提供者.
首先,进入 Ceph官网文档 查看其安装部署方法,主要看下是否有基于K8S的安装方法,最后在官网“ Installing ceph>Recommended methods ”(推荐的Ceph安装方法)果然发现了基于K8S的安装方法:
Ceph官方推荐在K8S集群上使用Rook来部署和管理Ceph集群! 。
我们进入 Rook官网 看看,从官网可以看出Rook是为K8S量身定制的,那就它了:
Ceph是一个在大规模生产集群中提供文件、块和对象存储的分布式存储系统,而Rook是一个专门支持Ceph与云原生环境集成的开源云原生存储协调器。Rook利用K8S的Operator机制推出了自己的Rook operator,实现自动化的Ceph部署和管理。Rook作为云原生存储平台已经从CNCF顺利毕业! 。
以上是对Rook简要说明,接下来借助Rook在K8S集群上部署和管理Ceph.
Rook支持K8S v1.19+的版本,CPU架构为amd64、x86_64或arm64均可 ,除此之外部署Ceph存储集群还必须 至少满足以下先决条件之一 :
这里我们选择为 K8S集群 的 每个工作节点 添加一块额外的未格式化磁盘(裸设备),步骤见以下截图:
将新增的磁盘设置成独立模式(模拟公有云厂商提供的独立磁盘),然后启动K8S集群虚拟机, 在工作节点上 使用以下命令检查一下磁盘条件是否符合Ceph部署要求:
[root@node1 ~]# lsblk - f NAME FSTYPE LABEL UUID MOUNTPOINT sdb sr0 iso9660 CentOS 7 x86_64 2020 - 11 - 04 - 11 - 36 - 43 - 00 sda ├─sda2 LVM2_member 45inUD -qJ4O-Fq9E-L6KD-8eJV-mofD- BuJDq6 │ └─centos_node1 - root xfs 704f37f0 -ae59- 4995 -80ec-58cba66e023b / └─sda1 xfs 67243cc8 -c3fb-490f-b0da-cc439371d5e1 /boot
上述命令输出中 sdb 磁盘就是我们为工作节点新添加的裸设备(它的FSTYPE为空),我们可以把它分配给Ceph使用.
需要在K8S集群中启用Rook准入控制器 ,用于验证使用自定义资源(CR)正确地配置了Rook。该准入控制器在身份认证和授权之后并在持久化对象之前,拦截发往K8S API Server的请求以进行验证。我们 在安装Rook之前 ,使用以下命令在K8S集群中安装Rook准备入控制器:
#在master1节点直接应用在线yaml文件 kubectl apply -f https: // github.com/jetstack/cert-manager/releases/download/v1.7.1/cert-manager.yaml #在master1将cert - manager.yaml下载到本地的方式( 推荐 ) kubectl apply -f /etc/kubernetes/rook/cert-manager.yaml
...... service /cert- manager created service /cert-manager- webhook created deployment.apps /cert-manager- cainjector created deployment.apps /cert- manager created deployment.apps /cert-manager- webhook created mutatingwebhookconfiguration.admissionregistration.k8s.io /cert-manager- webhook created validatingwebhookconfiguration.admissionregistration.k8s.io /cert-manager-webhook created
另外, Ceph OSD在以下情况下需要依赖于LVM(逻辑卷,OSD是Ceph用于在各个存储节点实现存储功能的组件) :
在以下情况下OSD不需要LVM 。
目前大多数Linux发生版的LVM由lvm2包提供,在K8S集群中运行Ceph OSD的所有存储节点上都需要有这个包。虽然没有这个包Rook也能够成功创建Ceph OSD,但是当相应的节点(node)重启之后,其上运行的OSD pod将会启动失败。所以需要确保作为存储节点的操作系统上安装了LVM(从上面磁盘条件查验的结果中看到我们是有LVM卷的),CentOS可以使用以下命令安装LVM:
sudo yum install -y lvm2
Ceph需要一个带有RBD模块的Linux内核 。大多数Linux发行版都有这个模块,但不是所有,你可以在K8S集群的存储节点上运行 lsmod|grep rbd 命令检测一下,如果该命令返回空,那说明当前系统内核没有加载RBD模块,可以使用以下命令尝试加载RBD模块:
#将RBD模块加载命令放入开机加载项里 cat > /etc/sysconfig/modules/rbd.modules << EOF # !/bin/ bash modprobe rbd EOF #为上述为脚本添加执行权限 chmod +x /etc/sysconfig/modules/ rbd.modules #执行上述脚本(如果返回'not found',你可能需要安装一个新的内核、或重新编译一个带有RBD模块的内核、或换一个带有RBD的Linux 发行版) /bin/bash /etc/sysconfig/modules/rbd .modules #查看RBD模块是否加载成功 lsmod | grep rbd
Rook默认的RBD配置只指定了分层特性,以便与较旧的内核广泛兼容。如果K8S节点运行在5.4+的系统内核上,则可以启用其他功能特性。例如特别有用的 fast-diff 和 object-map 特性,主要的功能特性如下(在进行 块存储 的StorageClass定义时指定):
imageFeatures : layering,fast- diff , object -map,deep-flatten,exclusive-lock
如果你将来会从Ceph共享文件系统(CephFS)创建卷(volume),那么需要使用4.17+的系统内核,PVC请求的存储配额只在高于该版本的内核上生效.
------------------------------- 以上为使用Rook在K8S集群部署Ceph存储的前提条件 ------------------------------- 。
接下来正式使用Rook在K8S集群部署Ceph存储集群! 。
首先在K8S所有集群节点上安装Git客户端( 用于拉取Rook部署组件清单 ):
#安装Git yum install - y git #查看Git版本 git -- version git version 1.8 . 3.1
使用Rook官方提供的示例部署组件清单(manifests)部署一个简单的Ceph集群(测试环境够用了):
#使用git将部署组件清单示例下载到本地(慢或无法接通的话自己想法办FQ) git clone --single-branch --branch v1. 10.11 https: // github.com/rook/rook.git #进入到本地部署组件清单示例目录 cd rook /deploy/ examples #执行以下命令将Rook和Ceph相关CRD资源和通用资源创建到K8S集群( 其中psp.yaml是K8S集群受Pod安全策略保护的情况下的可选资原文件 ) kubectl create -f crds.yaml -f common.yaml -f psp.yaml
接下来部署Rook Operator组件,该组件为Rook与Kubernetes交互的组件,整个集群只需要一个副本,特别注意 Rook Operator 的配置在Ceph集群安装后不能修改,否则Rook会删除Ceph集群并重建, 所以部署之前一定要做好规划,修改好operator.yaml的相关配置:
修改 rook/deploy/examples/operator.yaml文件中的以下内容:
#修改镜像地址为华中科技大学和阿里云的(可以使用docker pull <url> 验证一下,原来的地址很难下载) ROOK_CSI_CEPH_IMAGE: " quay.mirrors.ustc.edu.cn/cephcsi/cephcsi:v3.7.2 " ROOK_CSI_REGISTRAR_IMAGE: " registry.aliyuncs.com/google_containers/csi-node-driver-registrar:v2.7.0 " ROOK_CSI_RESIZER_IMAGE: " registry.aliyuncs.com/google_containers/csi-resizer:v1.7.0 " ROOK_CSI_PROVISIONER_IMAGE: " registry.aliyuncs.com/google_containers/csi-provisioner:v3.4.0 " ROOK_CSI_SNAPSHOTTER_IMAGE: " registry.aliyuncs.com/google_containers/csi-snapshotter:v6.2.1 " ROOK_CSI_ATTACHER_IMAGE: " registry.aliyuncs.com/google_containers/csi-attacher:v4.1.0 " #生产环境一般都会将裸设备自动发现开关设为true(方便后面追加设备) ROOK_ENABLE_DISCOVERY_DAEMON: " true " #打开CephCSI 提供者的节点(node)亲和性(去掉前面的注释即可,会同时作用于CephFS和RBD提供者,如果要分开这两者的调度,可以继续打开后面专用的节点亲和性) CSI_PROVISIONER_NODE_AFFINITY: " role=storage-node; storage=rook-ceph " #如果CephFS和RBD提供者的调度亲各性要分开,则在上面的基础上继打开它们专用的开关(去除下面两行前端的#即可) # CSI_RBD_PROVISIONER_NODE_AFFINITY: " role=rbd-node " # CSI_CEPHFS_PROVISIONER_NODE_AFFINITY: " role=cephfs-node " #打开CephCSI 插件的节点(node)亲和性(去掉前面的注释即可,会同时作用于CephFS和RBD插件,如果要分开这两者的调度,可以继续打开后面专用的节点亲和性) CSI_PLUGIN_NODE_AFFINITY: " role=storage-node; storage=rook-ceph " #如果CephFS和RBD提供者的调度亲各性要分开,则在上面的基础上继打开它们专用的开关(去除下面两行前端的#即可) # CSI_RBD_PLUGIN_NODE_AFFINITY: " role=rbd-node " # CSI_CEPHFS_PLUGIN_NODE_AFFINITY: " role=cephfs-node " #rook -ceph-operator的Deployment中的容器镜像地址rook/ceph:v1. 10.11 可以不用换,下载还是很快的! #生产环境一般还会打开裸设备自动发现守护进程(方便后期增加设备) ROOK_ENABLE_DISCOVERY_DAEMON: " true " #同时开打发现代理的节点亲和性环境变量 - name: DISCOVER_AGENT_NODE_AFFINITY value: " role=storage-node; storage=rook-ceph "
确认修改完成后,在master1节点上执行以下命令进行Rook Ceph Operator的部署:
#执行以下命令在K8S集群中部署Rook Ceph Operator(镜像拉取可能需要一定时间,耐心等待,可用后一条命令监控相关Pod部署情况) kubectl create - f operator.yaml #使用以下命令监控Rook Ceph Operator相关Pod的部署情况(rook - ceph为默认Rook Ceph Operator部署命名空间) watch kubectl get pods -n rook-ceph
确保rook-ceph-operator相关Pod都运行正常的情况下,修改 rook/deploy/examples/cluster.yaml文件中的以下内容:
# enable prometheus alerting for cluster(为集群打开prometheus告警) monitoring: # requires Prometheus to be pre - installed enabled : true #打开节点亲和性调度和污点容忍 # To control where various services will be scheduled by kubernetes, use the placement configuration sections below. # The example under ' all ' would have all services scheduled on kubernetes nodes labeled with ' role=storage-node ' and # tolerate taints with a key of ' storage-node ' . placement: all: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: role operator: In values: - storage- node # podAffinity: # podAntiAffinity: # topologySpreadConstraints: # tolerations: # - key: storage- node # operator: Exists #将存储设置为我们三个工作节点新加的sdb裸盘 storage: # cluster level storage configuration and selection useAllNodes : false useAllDevices : false #deviceFilter: config: # crushRoot: " custom-root " # specify a non-default root label for the CRUSH map # metadataDevice: " md0 " # specify a non-rotational storage so ceph- volume will use it as block db device of bluestore. # databaseSizeMB: " 1024 " # uncomment if the disks are smaller than 100 GB # journalSizeMB: " 1024 " # uncomment if the disks are 20 GB or smaller # osdsPerDevice: " 1 " # this value can be overridden at the node or device level # encryptedDevice: " true " # the default value for this option is " false " # Individual nodes and their config can be specified as well, but ' useAllNodes ' above must be set to false . Then, only the named # nodes below will be used as storage resources. Each node ' s ' name ' field should match their ' kubernetes.io/ hostname ' label. nodes: - name: " node1 " devices: # specific devices to use for storage can be specified for each node - name: " sdb " - name: " node2 " devices: # specific devices to use for storage can be specified for each node - name: " sdb " - name: " node3 " devices: # specific devices to use for storage can be specified for each node - name: " sdb " # - name: " nvme01 " # multiple osds can be created on high performance devices # config: # osdsPerDevice: " 5 " # - name: " /dev/disk/by-id/ata-ST4000DM004-XXXX " # devices can be specified using full udev paths # config: # configuration can be specified at the node level which overrides the cluster level config # - name: " 172.17.4.301 " # deviceFilter: " ^sd. " # when onlyApplyOSDPlacement is false , will merge both placement.All() and placement.osd onlyApplyOSDPlacement: false
修改完后,根据我们在operator.yaml和cluster.yaml上的节点标签亲和性设置,为 三个工作节点打上对应的标签 :
kubectl label nodes node1 node2 node3 role=storage- node kubectl label nodes node1 node2 node3 storage =rook-ceph
#确保工作节点打上对应标签,并且cluster文件修改好后,就可以使用cluster.yaml部署Ceph存储集群了(部署需要一定的时间,可用后一条命令监控)
kubectl
create
-f cluster.yaml
#使用以下命令监控Ceph Cluster相关Pod的部署情况(rook-
ceph为默认部署命名空间)
watch kubectl
get pods
-n rook-ceph
未完待续... 。
。
最后此篇关于为K8S集群准备Ceph存储的文章就讲到这里了,如果你想了解更多关于为K8S集群准备Ceph存储的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。
大家好,我刚开始接触 ceph 对象存储,即 radosgateway,为此目的,已经推出了一个非常基本的单节点 ceph/daemon docker 容器,它对 s3cmd 和 java s3 AP
我正在使用 kubernetes v1.16.10 与 Ceph 13.2.2 模仿版 通过 进行动态卷配置的集群ceph-csi . 但后来我找到了 ceph-rbd Ceph RBD (kuber
我读过 this article调整 Ceph 的 block 大小可以提高其性能。那是怎么设置的? This document解释了如何设置 strip 大小。这就是第一篇文章中“ block 大小
我们使用 CEPH 集群来存储我们的虚拟机的图像。该集群包含 3 个监视器、4 个存储节点和 1 个管理员。 CEPH OSD 树 ID WEIGHT TYPE NAME UP/DOW
我正在尝试使用此处的快速入门指南设置 Ceph 存储集群:http://docs.ceph.com/docs/master/start/quick-ceph-deploy/ 当我尝试使用此命令部署管理
不久前,我们从 Ceph 集群中删除了两个损坏的 OSD,osd.0 和 osd.8。它们现在从大多数 Ceph 命令中消失了,但仍然以奇怪的设备名称出现在 CRUSH 映射中: # devices
我正在尝试使用rook在kubernetes集群上配置ceph,我已经运行了以下命令: kubectl apply -f common.yaml kubectl apply -f operator.y
我无法理解,我的 ceph 原始空间在哪里不见了。 cluster 90dc9682-8f2c-4c8e-a589-13898965b974 health HEALTH_WARN 72 pg
在 Internet 上运行 CEPH 集群时是否有任何安全问题? 我无法直接找到使其无法用于此用例的东西。我不需要低 I/O 响应时间,我很好。 谢谢你们。 最佳答案 虽然集群守护进程的身份验证由
我是 Ceph 的新用户。 我的 Ceph 服务器运行的是 12.2.5 版。它有 3 个节点,每个节点有 1 个 OSD 和 4TB HDD。 ceph.conf osd pool default
可以帮我解决以下问题。 我如何计算总可用的 ceph 存储空间。 假设我有 3 个节点,每个节点有 6 个 1TB 磁盘的 OSD。那是总共 18TB 存储(3* 6TB)。所有这些 18TB 空间都
因此Ceph在librbd中有一个用户空间页面缓存实现。它是否允许用户提及要分配给每个Pod的页面缓存量?如果是,我们可以动态更改分配吗? 最佳答案 根据项目github中的文档和问题,没有引用POD
在学习 Ceph 时,我不小心删除了 client.admin,使用 ceph auth del client.admin 现在我明白了 client.admin authentication err
我正在尝试在 Ceph Nautilus 14.2.19 上的 Centos 7 上手动创建 ceph-mds。 首先我在 /var/lib/ceph/mds 中创建了一个文件夹格式为 -mds.然后
我有一个带有 data_pool 的 66 个 OSD 的 Ceph 集群和一个 metadata_pool . 我想放置metadata_pool在 3 个具有 SSD 的特定 OSD 上,因为所有
我用 cephadm 配置了一个简单的 Ceph 集群,如下所示: cephadm bootstrap --mon-ip 192.168.0.4 ssh-copy-id -f -i /etc/ceph
我正在尝试使用 storageClass 设置我的 Kubernetescluster 和 Ceph 集群,这样每个 PVC 都会在 ceph 集群内自动创建一个新 PV。 但它不起作用。我已经尝试了
有人成功地使用 kubernetes 创建了一个在 docker 容器中安装 ceph rbd 的 pod 吗? 来自 kubernetes 的以下示例使用安装了 ceph 二进制文件的 Fedora
嘿,我正在尝试使用 Ceph 来存储一些数据,但有一个问题,我写入 Ceph 的内容和通过 librados++ 从 Ceph 读取的内容是不一样的。 所以我有这个简单的例子: #include #
在我的本地集群(4 个 Raspberry PI)中,我尝试配置 rgw 网关。不幸的是,该服务在 2 分钟后自动消失。 [ceph_deploy.rgw][INFO ] The Ceph Obje
我是一名优秀的程序员,十分优秀!