文章目录
ceph应用场景
官网文档：Ceph Docs
- 对象存储（Ceph Object Storage）：
对象存储适用于需要存储和访问大量非结构化数据的场景，例如图像、视频、日志文件等。在 Kubernetes 中，可以使用 Ceph Rados Gateway 提供的对象存储接口，将应用程序的对象数据存储在 Ceph 集群中。对象存储提供了高可扩展性和高可靠性，并且可以通过 HTTP 或 S3 API 进行访问。 - 块存储（Ceph Block Storage）：
块存储适用于需要将持久化数据作为块设备挂载到容器中的场景，例如数据库、文件系统等应用。在 Kubernetes 中，可以使用 Ceph RBD（Rados Block Device）提供的块存储功能。通过创建和管理 RBD 卷，可以将块设备挂载到 Pod 中，以提供高性能和可靠的块存储。 - 文件系统（Ceph File System）：
文件系统适用于需要共享文件数据的场景，例如共享配置文件、共享存储卷等。在 Kubernetes 中，可以使用 CephFS（Ceph File System）作为持久化存储卷，将文件系统挂载到多个 Pod 中，实现文件级别的共享和访问。CephFS 提供了高性能和可扩展的分布式文件系统功能。
总结来说，Ceph 对象存储适用于存储大量非结构化数据，块存储适用于需要挂载块设备的应用，文件系统适用于需要共享文件数据的场景。根据应用的需求和特点，选择适合的 Ceph 存储方式可以提供高性能、可靠性和可扩展性的存储解决方案。
ceph应用
在k8s集群外使用块设备
ceph客户端配置
- 通过rook-ceph-tools工具查看配置
java
sh-4.4$ cat /etc/ceph/ceph.conf
[global]
mon_host = 192.168.31.25:6789,192.168.31.24:6789,192.168.31.20:6789
[client.admin]
keyring = /etc/ceph/keyring
sh-4.4$ cat /etc/ceph/keyring
[client.admin]
key = AQBaFp1lEAyWNRAAmSeFCljy78bBBH3+D0qkmw==- 将上述配置在其他机器创建，
确保其他机器能访问上述mon_host配置的ip:port。mon_host配置ip为宿主集群ip，需将cluster.yaml中provider: host配置注释放开，不然使用的是k8s集群中service的虚拟vip，需修改上述配置
yaml
# 宿主机上查看是否暴露端口
[root@ksnode20 ~]# ss -anput | grep ":6789"
tcp LISTEN 0 128 192.168.31.20:6789 *:* users:(("ceph-mon",pid=19223,fd=28))- 确定centos版本和下载源
java
# 查看el版本
cat /etc/redhat-release
#CentOS Linux release 7.5.1804 (Core)
# 对应el7版本
# rook-ceph-tools中查看
sh-4.4$ cat /etc/redhat-release
CentOS Stream release 8- 查看版本
java
# rook-ceph-tools中查看ceph版本
sh-4.4$ ceph -v
ceph version 16.2.10 (45fa1a083152e41a408d15505f594ec5f1b4fe17) pacific (stable)- 下载ceph客户端
java
vi /etc/yum.repos.d/ceph.repo
# 添加如下内容，https://mirrors.aliyun.com/ceph找到相应版本
[ceph]
name=ceph
baseurl=https://mirrors.aliyun.com/ceph/rpm-16.2.10/el8/x86_64/
enabled=1
gpgcheck=0
####安装客户端
yum install ceph-common -y- 测试
java
sh-4.4$ ceph -s
cluster:
id: b4e4ce76-8a0c-4171-a5ec-27da6394983e
health: HEALTH_OK
services:
mon: 3 daemons, quorum a,b,c (age 21h)
mgr: b(active, since 21h), standbys: a
osd: 5 osds: 5 up (since 21h), 5 in (since 21h)
data:
pools: 1 pools, 1 pgs
objects: 0 objects, 0 B
usage: 27 MiB used, 2.4 TiB / 2.4 TiB avail
pgs: 1 active+cleanCeph是一个开源的分布式存储系统，提供了丰富的命令行工具来管理和操作Ceph集群。以下是一些常用的Ceph命令：
java
1. ceph-deploy: 用于在Ceph集群中部署和管理节点。
2. ceph: 主要命令行工具，用于执行各种Ceph管理操作。
ceph health: 检查Ceph集群的健康状态。
ceph status: 显示Ceph集群的状态信息。
ceph osd status: 显示Ceph集群中每个OSD（对象存储设备）的状态信息。
ceph df: 显示Ceph集群的存储使用情况。
ceph osd pool ls: 列出Ceph集群中的所有存储池。
ceph osd pool stats: 显示Ceph集群中每个存储池的统计信息。
ceph osd tree: 显示Ceph集群中的OSD树结构。
ceph pg stat: 显示Ceph集群中PG（Placement Group）的状态信息。
ceph pg dump: 显示Ceph集群中PG的详细信息。
ceph osd crush tree: 显示Ceph集群中的CRUSH映射树结构。
ceph osd lspools: 列出Ceph集群中的所有存储池。
3. rados: 用于执行与RADOS（可靠自动分布式对象存储）相关的操作。
rados df: 显示RADOS集群的存储使用情况。
rados ls: 列出RADOS集群中的所有对象。
rados rm: 删除RADOS集群中的对象。
rados put: 将文件上传为RADOS对象。
rados get: 从RADOS集群中下载对象。
4. rbd: 用于执行与RBD（块设备）相关的操作。
rbd create: 创建一个RBD镜像。
rbd ls: 列出RBD镜像。
rbd info: 显示RBD镜像的详细信息。
rbd map: 将RBD镜像映射为块设备。
rbd unmap: 解除RBD镜像的块设备映射。
rbd resize: 调整RBD镜像的大小。
rbd snap create: 创建RBD镜像的快照。
rbd snap ls: 列出RBD镜像的快照。
rbd snap rm: 删除RBD镜像的快照。创建块挂载使用
- 创建pool
java
# 该命令的作用是在 Ceph 存储集群中创建一个名为 "rook" 的 OSD 池，初始设置为具有 16 个 PG 和至少 16 个副本
sh-4.4$ ceph osd pool create rook 16 16
pool 'rook' created
# 用于列出 Ceph 存储集群中存在的所有 OSD 池
sh-4.4$ ceph osd lspools
1 device_health_metrics
2 rook
- ceph osd pool create：这是 Ceph 命令行工具的一部分，用于创建 OSD 池。
- rook：这是要创建的 OSD 池的名称。您可以根据自己的需求选择一个合适的名称。
- 16：这是指定 OSD 池的初始 PG（Placement Group）数量。PG 是 Ceph 存储集群中数据分布和负载均衡的单位。选择适当的 PG 数量对于性能和数据分布非常重要。根据集群的大小和负载情况，您可以根据需要调整这个数字。
- 16：这是指定 OSD 池的最小副本数。Ceph 使用副本（replication）来提供数据冗余和高可用性。设置最小副本数将确保在发生故障时仍然有足够的副本可用。同样，您可以根据需求调整这个数字。
- 在pool上创建RDB块
java
# 在名为 "rook" 的 OSD 池中创建一个名为 "rook-rbd.img" 的 RBD 镜像，其大小为 1GB
sh-4.4$ rbd create -p rook --image rook-rbd.img --size 1G
# 获得名为 "rook" 的 OSD 池中所有 RBD 镜像的列表
sh-4.4$ rbd ls -p rook
rook-rbd.img- 客户端挂载块
java
# 将指定的 RBD 镜像映射到本地系统中，使其在本地系统上可用。映射后，该镜像将作为块设备出现，并可以像其他块设备一样进行读取和写入操作。
rbd map rook/rook-rbd.img
# 在/dev/rbd0设备上创建一个XFS文件系统。这将格式化该设备，并将其准备好以存储文件和目录
mkfs.xfs /dev/rbd0
# 挂载
mount /dev/rbd0 /media
删除pool
要删除 Ceph 中的池（Pool），可以按照以下步骤进行操作：
-
检查池状态：运行以下命令，确保要删除的池处于健康状态（HEALTH_OK）：
ceph -s
-
停止池中的操作：在删除池之前，最好停止对该池的任何操作，以确保数据的完整性。可以使用以下命令暂停池中的 I/O 操作：
#查看pool列表
ceph osd pool lsceph osd pool set <pool-name> size 0
-
删除池：运行以下命令删除池：
ceph osd pool delete <pool-name> <pool-name> --yes-i-really-really-mean-it
ceph osd pool delete rook rook --yes-i-really-really-mean-it
将 替换为要删除的池的名称。请注意，这是一个不可逆的操作，所有池中的数据将被永久删除。因此，请谨慎执行此命令，并确保已备份重要数据。
-
确认删除：运行以下命令确认池已被删除：
ceph osd lspools
检查输出中是否不再包含已删除的池。
请注意，删除池是一个潜在的危险操作，需要谨慎处理。在执行删除操作之前，请确保已备份重要数据，并确保不再需要该池中的任何数据。建议在删除池之前，仔细评估并确认操作的后果，并参考 Ceph 官方文档获取更多详细的指导和建议。
在k8s集群内使用块设备
块存储允许单个 Pod 挂载存储。官网参考文档：https://rook.io/docs/rook/v1.9/ceph-block.html
创建块池和StorageClass
- 编辑storageclass.yaml
yaml
# 指定所使用的API版本，这里使用的是Ceph Rook的API版本
apiVersion: ceph.rook.io/v1
# 指定资源的类型为CephBlockPool，表示创建一个Ceph块池。
kind: CephBlockPool
# 元数据部分，用于定义资源的元数据信息。
metadata:
# 指定资源的名称为"replicapool"，这是创建的Ceph块池的名称。
name: replicapool
# 指定资源所属的命名空间为"rook-ceph"，命名空间用于对资源进行逻辑隔离和管理。
namespace: rook-ceph
# 规格部分，用于定义资源的配置规格
spec:
# 指定故障域为"host"，表示块池的数据副本将在不同的主机上进行分布，以提高数据的容错性和可用性。
failureDomain: host
# 指定块池的复制方式为"replicated"，表示数据将以复制的方式进行存储。
replicated:
# 指定复制的副本数为3，表示每个数据块将被复制为3个副本。
size: 3
# 设置为true，表示要求每个副本都处于安全状态，确保数据的完整性和可靠性。
requireSafeReplicaSize: true
---
# 指定所使用的API版本，这里使用的是Kubernetes的存储API版本。
apiVersion: storage.k8s.io/v1
# 指定资源的类型为StorageClass，表示创建一个存储类。
kind: StorageClass
# 元数据部分，用于定义资源的元数据信息。
metadata:
# 指定资源的名称为"rook-ceph-block"，这是创建的存储类的名称。
name: rook-ceph-block
# 指定存储类的提供者为"rook-ceph.rbd.csi.ceph.com"，表示使用Rook Ceph提供的CSI插件进行存储。
provisioner: rook-ceph.rbd.csi.ceph.com
# 参数部分，用于定义存储类的配置参数
parameters:
# 指定集群ID为"rook-ceph"，表示使用名为"rook-ceph"的Ceph集群。
clusterID: rook-ceph # namespace:cluster
# 指定使用的Ceph块池为"replicapool"，表示存储数据的块池名称。
pool: replicapool
# 指定存储的镜像格式为"2"，表示使用Ceph的版本2镜像格式。
imageFormat: "2"
# 指定镜像特性为"layering"，表示启用镜像层级特性。
imageFeatures: layering
# 指定CSI插件的提供者密钥名称为"rook-csi-rbd-provisioner"，用于访问Rook Ceph提供的存储。
csi.storage.k8s.io/provisioner-secret-name: rook-csi-rbd-provisioner
# 指定CSI插件的提供者密钥所在的命名空间为"rook-ceph"。
csi.storage.k8s.io/provisioner-secret-namespace: rook-ceph
# 指定CSI插件的控制器扩展密钥名称为"rook-csi-rbd-provisioner"。
csi.storage.k8s.io/controller-expand-secret-name: rook-csi-rbd-provisioner
# 指定CSI插件的控制器扩展密钥所在的命名空间为"rook-ceph"。
csi.storage.k8s.io/controller-expand-secret-namespace: rook-ceph
# 指定CSI插件的节点阶段密钥名称为"rook-csi-rbd-node"。
csi.storage.k8s.io/node-stage-secret-name: rook-csi-rbd-node
# 指定CSI插件的节点阶段密钥所在的命名空间为"rook-ceph"。
csi.storage.k8s.io/node-stage-secret-namespace: rook-ceph
# 指定文件系统类型为"ext4"，表示使用ext4文件系统进行挂载。
csi.storage.k8s.io/fstype: ext4
# 设置为true，表示允许对该存储类的卷进行扩展。
allowVolumeExpansion: true
# 指定回收策略为"Delete"，表示当卷被删除时，相关的存储资源也会被删除。
reclaimPolicy: Delete-
创建资源
kubectl create -f deploy/examples/csi/rbd/storageclass.yaml
ALLOWVOLUMEEXPANSION是Kubernetes中存储类（StorageClass）的一个属性，用于指示该存储类是否允许卷的扩展（容量增加）。
当存储类的 ALLOWVOLUMEEXPANSION 属性设置为 true 时，表示该存储类允许动态卷的扩展。这意味着在使用该存储类创建的卷上，可以通过修改卷的容量来增加其存储空间。扩展卷的过程可以是在线的，而不需要中断应用程序的运行。
如果存储类的 ALLOWVOLUMEEXPANSION 属性设置为 false 或未设置（默认值为 false），则不允许对使用该存储类创建的卷进行扩展。在这种情况下，如果需要增加卷的容量，通常需要创建一个新的卷，并将数据从旧卷迁移到新卷。
要注意的是，存储后端必须支持卷的扩展功能，并且相应的存储插件和驱动程序也必须进行相应的配置和支持。因此，在使用 ALLOWVOLUMEEXPANSION 属性之前，需要确保存储后端和相关组件都支持卷扩展操作。
要查看存储类是否允许卷扩展，可以使用 kubectl describe storageclass <storageclass_name> 命令，并查找 AllowVolumeExpansion 字段的值。
使用存储
下述操作可直接在kubesphere中可视化操作
- 创建PVC资源
上述操作生成的资源文件内容如下：
yaml
# 指定要创建的资源类型为持久卷声明
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
# 指定持久卷声明的名称为 "rook-ceph-block-pvc"
name: rook-ceph-block-pvc
namespace: rook-ceph
annotations:
kubesphere.io/creator: admin
pv.kubernetes.io/bind-completed: 'yes'
pv.kubernetes.io/bound-by-controller: 'yes'
volume.beta.kubernetes.io/storage-provisioner: rook-ceph.rbd.csi.ceph.com
volume.kubernetes.io/storage-provisioner: rook-ceph.rbd.csi.ceph.com
finalizers:
- kubernetes.io/pvc-protection
# 指定持久卷声明的规格和配置
spec:
# 指定卷的访问模式，这里使用了 "ReadWriteOnce"，表示该卷可以被单个节点以读写方式挂载。
accessModes:
- ReadWriteOnce
resources:
requests:
# # 指定需要 10GB 的存储容量
storage: 10Gi
volumeName: pvc-23ae523d-6b0c-423f-b2ed-748a7758d7b9
# # 指定存储类的名称为 "rook-ceph-block"。这将告诉 Kubernetes 使用名为 "rook-ceph-block" 的存储类来提供持久卷。
storageClassName: rook-ceph-block
volumeMode: Filesystem- pod引用PVC
java
apiVersion: apps/v1
kind: Deployment
metadata:
name: wordpress-mysql
labels:
app: wordpress
tier: mysql
spec:
selector:
matchLabels:
app: wordpress
tier: mysql
strategy:
type: Recreate
template:
metadata:
labels:
app: wordpress
tier: mysql
spec:
containers:
- image: mysql:5.6
name: mysql
env:
- name: MYSQL_ROOT_PASSWORD
value: changeme
ports:
- containerPort: 3306
name: mysql
volumeMounts:
- name: mysql-persistent-storage
mountPath: /var/lib/mysql
volumes:
- name: mysql-persistent-storage
persistentVolumeClaim:
claimName: mysql-pv-claim块存储映射问题处理
问题现象
当操作执行如下命令：
bash
kubectl create -f deploy/examples/csi/rbd/storageclass.yaml
kubectl create -f mysql.yaml
kubectl create -f wordpress.yaml上述命令执行现象如下：
事件分析
bash
MountVolume.MountDevice failed for volume "pvc-541330c2-c399-4d33-a6dc-a2e1146ae87d" : rpc error: code = Internal desc = rbd: map failed with error an error (exit status 95) occurred while running rbd args: [--id csi-rbd-node -m 192.168.31.24:6789,192.168.31.20:6789,192.168.31.25:6789 --keyfile=***stripped*** map replicapool/csi-vol-b6def63c-afa0-11ee-a3c0-923efe8ba7cc --device-type krbd --options noudev], rbd error output: rbd: sysfs write failed rbd: map failed: (95) Operation not supported具体是由于 rbd（RADOS Block Device）映射失败而导致的。错误消息中提到了 "Operation not supported"，这可能是由于以下原因之一引起的：
- 内核模块未加载 ：确保在执行 rbd 操作之前，已加载了正确的内核模块。在节点上执行以下命令加载内核模块：
modprobe rbd - 缺少依赖软件包：确保节点上安装了必要的软件包，包括 Ceph 和 RBD 相关的软件包。具体所需的软件包可能因操作系统和安装方式而异。请参考 Ceph 和 Rook 的官方文档，查找正确的软件包依赖关系并进行安装。
- 内核版本不兼容：某些内核版本可能不完全支持 rbd 映射功能。尝试升级或更换到支持的内核版本。请参考 Ceph 和 Rook 的官方文档，了解支持的内核版本要求。
- 硬件限制：某些硬件环境可能不支持 rbd 映射操作。确保硬件环境满足 rbd 映射的要求。如果使用的是虚拟化环境，请检查虚拟化平台的文档，确认是否支持 rbd 映射。
- SELinux 或安全策略限制：如果启用了 SELinux 或其他安全策略，可能会限制 rbd 映射操作。请检查安全策略配置，并相应地调整以允许 rbd 映射。
请根据你的环境和具体情况逐一检查这些可能的原因，并采取适当的措施来解决问题。如果问题仍然存在，建议参考 Ceph、Rook 和 Kubernetes 相关的官方文档和社区支持资源，以获取更深入的故障排除和解决方案。
bash
Unable to attach or mount volumes: unmounted volumes=[wordpress-persistent-storage], unattached volumes=[kube-api-access-54dwt wordpress-persistent-storage]: timed out waiting for the condition这个错误消息表明在附加或挂载卷时遇到了问题。错误消息中提到了超时等待条件，可能是由于以下原因之一引起的：
- 存储类配置错误：检查所使用的存储类（StorageClass）配置是否正确。确保存储类指定了正确的卷插件和参数，并与底层存储系统兼容。可以通过运行 kubectl describe storageclass 命令来查看存储类的详细信息，并确保其配置正确。
- 存储系统故障：如果底层存储系统出现故障或不可用，可能导致挂载卷超时。确保存储系统正常运行，并且与 Kubernetes 集群连接正常。检查存储系统的日志和状态，以确定是否存在任何问题。
- 节点资源不足：如果节点上的资源（例如 CPU、内存、存储）不足，可能导致挂载卷超时。检查节点的资源使用情况，确保节点具有足够的资源来处理卷挂载操作。
- 网络问题：网络问题可能导致挂载卷超时。确保网络连接正常，并且 Kubernetes 集群中的各个组件可以相互通信。检查网络配置和防火墙设置，确保没有阻止卷挂载所需的流量。
- 存储系统性能问题：如果底层存储系统的性能不足，可能导致挂载卷超时。检查存储系统的性能指标，并确保其能够处理所需的读写操作。
在解决问题之前，建议备份重要数据，并参考 Kubernetes 和底层存储系统的官方文档，以获取更详细的故障排除步骤和支持。此外，查看 Kubernetes 事件日志和存储系统日志，以获取更多关于超时问题的详细信息。
bash
0/8 nodes are available: 8 pod has unbound immediate PersistentVolumeClaims.这个错误消息表明在调度 Pod 时遇到了问题，没有可用的节点。错误消息中提到有 8 个 Pod 的 PersistentVolumeClaims（PVC）处于未绑定状态，这可能是由以下原因之一引起的：
- 存储类配置错误：检查所使用的存储类（StorageClass）配置是否正确。确保存储类指定的卷插件和参数与底层存储系统兼容，并且有足够的可用存储容量。如果存储类配置错误，可能导致 PVC 无法绑定到可用的持久卷（PersistentVolume）。
- 持久卷不足：如果没有足够的可用持久卷来满足 PVC 的需求，可能导致 PVC 无法绑定。检查持久卷的状态和可用性，确保有足够的持久卷供应给 PVC 使用。
- 节点资源不足：如果节点上的资源（例如 CPU、内存、存储）不足，可能导致 Pod 无法调度。检查节点的资源使用情况，确保节点具有足够的资源来运行 Pod，并满足 PVC 的需求。
- 节点标签不匹配：如果节点的标签与 Pod 的调度要求不匹配，可能导致 Pod 无法调度到节点上。检查节点的标签和 Pod 的调度要求，确保它们匹配。
- 网络问题：网络问题可能导致节点无法与存储系统通信，从而导致 PVC 无法绑定。确保网络连接正常，并且节点可以访问存储系统。
- 存储系统故障：如果底层存储系统出现故障或不可用，可能导致 PVC 无法绑定。检查存储系统的状态和日志，以确定是否存在任何问题。
解决此问题的步骤可能包括检查存储类配置、持久卷可用性、节点资源、节点标签和网络连接。此外，查看 Kubernetes 事件日志和存储系统日志，以获取更多关于 PVC 绑定问题的详细信息。如果问题仍然存在，建议参考 Kubernetes 和底层存储系统的官方文档，以获取更详细的故障排除步骤和支持。
csi-rbdplugin pod日志分析
bash
W0110 10:42:47.457179 30223 rbd_attach.go:226] nbd modprobe failed (an error (exit status 1) occurred while running modprobe args: [nbd]): "modprobe: FATAL: Module nbd not found in directory /lib/modules/3.10.0-862.el7.x86_64\n"错误消息 "modprobe: FATAL: Module nbd not found in directory /lib/modules/3.10.0-862.el7.x86_64" 表明在您的 CentOS 系统中找不到名为 "nbd" 的内核模块。
nbd 是 Network Block Device 的缩写，它允许通过网络连接将远程块设备映射到本地系统。通常，nbd 模块应该存在于 /lib/modules/<kernel_version> 目录中，其中 <kernel_version> 是您当前使用的内核版本。
bash
W0111 01:23:26.200423 43637 util.go:250] kernel 3.10.0-862.el7.x86_64 does not support required features
W0111 01:23:26.814313 43637 rbd_attach.go:469] ID: 3562 Req-ID: 0001-0009-rook-ceph-0000000000000005-b22dcee8-b01d-11ee-879c-dab0780880f4 rbd: map error an error (exit status 95) occurred while running rbd args: [--id csi-rbd-node -m 192.168.31.25:6789,192.168.31.24:6789,192.168.31.20:6789 --keyfile=***stripped*** map replicapool/csi-vol-b22dcee8-b01d-11ee-879c-dab0780880f4 --device-type krbd --options noudev], rbd output: rbd: sysfs write failed
rbd: map failed: (95) Operation not supported错误消息 "rbd: map failed，kernel 3.10.0-862.el7.x86_64 does not support required features" 表明您的 CentOS 操作系统内核版本不支持所需的功能。
这个问题通常发生在使用 RBD (Rados Block Device) 时，该设备需要在内核中启用一些特定的功能。您的内核版本可能过旧，不支持所需的功能。
解决此问题的一种方法是升级您的内核版本。
问题小结
操作系统内核版本过低，内核中没有RBD内核模块，两种解决方案：（推荐安装rdb内核）
- 升级内核（影响大）
- 安装rdb内核模块（影响小）
CentOS 上升级内核可能对运行在其上的 Kubernetes (K8s) 环境产生一些影响。以下是一些可能的影响和注意事项：
- 容器运行时兼容性：在升级内核之前，您需要确保所选的内核版本与您使用的容器运行时兼容。不同的容器运行时可能对内核版本有特定的要求。您应该查看容器运行时的文档或支持页面，以了解其支持的内核版本范围。
- 内核模块和功能：升级内核可能会导致某些内核模块或功能的更改或移除。如果您的 Kubernetes 集群依赖于特定的内核模块或功能，您需要确保新的内核版本仍然支持这些要求。
- 容器网络：升级内核可能会对容器网络产生一些影响。某些网络插件或驱动程序可能需要与特定的内核版本配合使用。在升级内核之前，您应该检查您使用的容器网络插件或驱动程序的兼容性和支持情况。
- 安全性和性能改进：升级内核通常会带来安全性和性能方面的改进。新的内核版本可能修复了一些已知的漏洞或改进了系统性能。这些改进可能会对您的 Kubernetes 集群产生积极的影响，提供更好的安全性和性能。
- 测试和验证：在升级内核之前，建议您在非生产环境中进行测试和验证。您可以创建一个与生产环境相似的测试环境，并在该环境中进行内核升级。这样可以帮助您发现潜在的问题并解决它们，以确保升级过程顺利进行。
在进行任何重要的系统更改之前，包括内核升级，都建议您备份重要的数据和配置，以便在需要时进行恢复。此外，您还应该参考 CentOS 和 Kubernetes 的官方文档，以获取更详细的指导和建议，以确保您的升级过程正确无误。
CentOS 7 编译安装 nbd 模块
CentOS 7 编译安装 nbd 模块-CSDN博客
CentOS 7 安装 nbd - OrcHome
nbd内核模块介绍
"nbd" 是 Network Block Device（网络块设备）的缩写，它是一种允许通过网络连接将远程块设备映射到本地系统的内核模块。它提供了一种将远程存储设备（如硬盘、分区或镜像文件）映射为本地块设备的方法。
通过使用 nbd 内核模块，您可以在本地系统上像使用本地块设备一样使用远程存储设备。这对于需要远程访问和操作存储设备的应用程序和系统非常有用。
一些常见的用例包括：
- 在分布式存储系统中使用 nbd 将远程存储设备映射到本地系统，以实现高可用性和容错性。
- 在虚拟化环境中，将远程存储设备映射到虚拟机实例，以实现共享存储和迁移虚拟机的能力。
- 在云环境中，将远程存储设备映射到云实例，以实现持久化存储和数据共享。
要使用 nbd 内核模块，您需要加载该模块到内核中，并使用相应的工具配置和管理映射的远程块设备。具体操作和配置可能因操作系统和使用的工具而有所不同。
请注意，nbd 内核模块的可用性和功能取决于您的操作系统和内核版本。某些发行版可能已经将 nbd 内核模块包含在默认内核中，而其他发行版可能需要手动安装和配置。
在 Linux 系统中，nbd 内核模块通常位于 /lib/modules/<kernel_version>/kernel/drivers/block/nbd.ko 路径下，其中 <kernel_version> 是您当前使用的内核版本。
如果您需要使用 nbd 内核模块，请确保您的系统具有适当的权限，并按照操作系统和工具的文档进行安装和配置。
安装 nbd 模块
- 确认nbd内核模块是否安装
bash
[root@localhost ~]# modprobe nbd
modprobe: FATAL: Module nbd not found.- 查看 linux 版本
bash
[root@localhost ~]# cat /etc/redhat-release
CentOS Linux release 7.6.1810 (Core) #查看系统版本
[root@localhost ~]# uname -r #查看linux的内核信息
3.10.0-957.el7.x86_64- 安装相关包
bash
yum install kernel-devel kernel-headers elfutils-libelf-devel gcc+ gcc-c++ -y- 下载内核包
找对应的kernel源码包，一般yum都是升级到最新的，因此到 http://vault.centos.org/ 的整个7系列的最新版本目录下去找：
bash
wget https://vault.centos.org/7.9.2009/os/Source/SPackages/kernel-3.10.0-1160.el7.src.rpm
# 根据自己的系统版本去下载
# 7.9.2009 为 redhat-release 系统版本
# 3.10.0-1160.102.1.el7 为 uname -r 内核信息- 编译
安装bzip2
bash
sudo yum install bzip2开始编译
bash
rpm -ivh kernel-3.10.0-957.el7.src.rpm
cd ~/rpmbuild/SOURCES/
# 验证文件，如果显示的类型不是 "XZ compressed data"，则可能是文件本身损坏或者文件类型不正确。
file linux-3.10.0-862.el7.tar.xz
#解压 -C 指定目录 /usr/src/kernels
tar Jxvf linux-3.10.0-957.el7.tar.xz -C /usr/src/kernels/
# 注意，这里使用的是大写的 J 选项，而不是之前的小写 j 选项。J 选项告诉 tar 命令使用 xz 工具来解压缩文件。
#解压后生成两个文件
ll /usr/src/kernels/
drwxr-xr-x. 22 root root 4096 9月 6 08:07 3.10.0-957.27.2.el7.x86_64
drwxrwxr-x. 24 root root 4096 9月 6 08:17 linux-3.10.0-957.el7
###############################
cd /usr/src/kernels/linux-3.10.0-957.el7
#删除所有编译生成文件，内核配置文件
make mrproper
cp /usr/src/kernels/3.10.0-957.27.2.el7.x86_64/Module.symvers ./
cp /boot/config-3.10.0-957.el7.x86_64 ./.config
#备份当前.config文件为.config.old
make oldconfig
make prepare
make scripts- 编译
修改配置
bash
vi drivers/block/nbd.c
#######################
// sreq.cmd_type = REQ_TYPE_SPECIAL;
sreq.cmd_type = 7; #修改为7编译
bash
make CONFIG_BLK_DEV_NBD=m M=drivers/block如果报以下错误：
bash
make[1]: *** No rule to make target tools/objtool/objtool', needed bydrivers/block/floppy.o'. Stop.则执行：
bash
make CONFIG_BLK_DEV_NBD=m M=drivers/block CONFIG_STACK_VALIDATION=- 复制文件
bash
cp drivers/block/nbd.ko /lib/modules/$(uname -r)/kernel/drivers/block/
depmod -a- 验证nbd是否安装成功
bash
modinfo nbd输出
bash
filename: /lib/modules/3.10.0-1160.102.1.el7.x86_64/kernel/drivers/block/nbd.ko
license: GPL
description: Network Block Device
retpoline: Y
rhelversion: 7.9
srcversion: 171F87FBEBE350C33C34226
depends:
vermagic: 3.10.0 SMP mod_unload modversions
parm: nbds_max:number of network block devices to initialize (default: 16) (int)
parm: max_part:number of partitions per device (default: 0) (int)
parm: debugflags:flags for controlling debug output (int)重新使用块存储验证
- 重建驱动程序
bash
kubectl delete po -l app=csi-cephfsplugin-provisioner -n rook-ceph
kubectl delete po -l app=csi-rbdplugin-provisioner -n rook-ceph
kubectl delete po -l app=csi-rbdplugin -n rook-ceph
kubectl delete po -l app=csi-cephfsplugin -n rook-ceph- 查看csi-rbdplugin
bash
W0111 05:13:24.427112 65526 util.go:250] kernel 3.10.0-862.el7.x86_64 does not support required features
W0111 05:13:24.427606 65526 rbd_attach.go:241] kernel version "3.10.0-862.el7.x86_64" doesn't support cookie feature最终确认是centos内核不支持，建议使用centos8或者升级centos，建议依据如下：
升级centos验证
先升级CentOS 操作系统验证，你可以按照以下步骤进行操作：
-
备份数据：在进行任何操作之前，强烈建议你备份重要的数据。升级过程可能会对系统进行更改，因此备份可以保护你的数据免受意外损失。
-
更新当前系统：在升级之前，确保你的当前系统已经是最新的状态。运行以下命令来更新已安装的软件包：
sudo yum update -y
这将更新系统上的所有已安装软件包到最新版本。
-
安装升级工具：CentOS 提供了一个名为 yum-utils 的软件包，其中包含了用于升级 CentOS 的工具。如果你的系统上没有安装该软件包，可以通过以下命令进行安装：
sudo yum install yum-utils
-
运行系统升级：一旦你安装了 yum-utils 工具，你可以使用 yum 命令来执行实际的系统升级。运行以下命令来升级 CentOS：
sudo yum upgrade
这将检查可用的更新并升级系统上的软件包。根据系统的大小和网络速度，升级过程可能需要一些时间。
-
重启系统：升级完成后，建议重新启动系统以应用所有更改。使用以下命令重新启动系统：
sudo reboot
重启后内核才会重新加载
-
验证升级：系统重新启动后，可以通过运行以下命令来验证 CentOS 的版本：
[root@ksnode25 ~]# cat /etc/redhat-release
CentOS Linux release 7.9.2009 (Core)[root@ksnode25 ~]# uname -r
3.10.0-1160.105.1.el7.x86_64[root@ksnode25 ~]# modprobe nbd
modprobe: FATAL: Module nbd not found.
升级后nbd需要重新安装
重新运行发现运行正常
bash
kubectl create -f mysql.yaml
kubectl create -f wordpress.yaml
查看rdb映射情况，进入mon pod终端执行：rbd showmapped
进入升级centos机器查看dev设备信息如下，说明验证成功
验证小结
升级centos后部署成功，由于centos不在维护，生产环境建议更换操作系统：
- Pacific(16.2.z)支持centos7和8
- ceph客户端发现只有el8版本，https://mirrors.aliyun.com/ceph/rpm-16.2.10/el8/x86_64/
- CentOS Linux停止维护，推出了CentOS Stream项目
- 查看rook-ceph-tools系统版本：CentOS Stream release 8
总结：综合上图可选择centos8和Ubuntu20.04替换centos7，但是生产环境不建议使用CentOS Linux（停止维护），也不建议使用CentOS Stream（无法保证系统的稳定性与兼容性），老项目不建议更换操作系统稳定运行就行。新项目可以考虑使用其他稳定操作系统。
操作系统选择考虑
从习惯和兼容性考虑，CentOS Linux 和 Rocky Linux。您可能想知道Rocky Linux是否适合您。如果您依赖CentOS而不想运行CentOS Stream或为RHL付费，那么当稳定版本可用时，您可以考虑Rocky Linux 。
rockylinux安装包下载_开源镜像站-阿里云
重庆大学开源软件镜像站
CentOS Linux 和 Rocky Linux 都是基于 RHEL（Red Hat Enterprise Linux）的操作系统，它们有很多相似之处，但也有一些区别。
- 起源和维护：
- CentOS Linux：CentOS Linux 是一个由社区维护的开源操作系统，它是基于 RHEL 的重构版本。在过去，CentOS Linux 通过重新编译 RHEL 的源代码来创建一个免费的替代品，并提供长期支持。
- Rocky Linux：Rocky Linux 是由 CentOS 创始人之一创建的一个社区驱动的企业级操作系统。它的目标是提供一个免费、开源的替代方案，以填补 CentOS Linux 停止维护的空白。
- 继承和兼容性：
- CentOS Linux：CentOS Linux 的目标是与 RHEL 完全兼容，并提供与 RHEL 相同的功能和特性。它通常会在 RHEL 发布后的一段时间内推出相应的更新，以确保与 RHEL 的兼容性。
- Rocky Linux：Rocky Linux 也是基于 RHEL 的代码构建的，旨在提供与 RHEL 完全兼容的功能和特性。它的设计目标是与 CentOS Linux 8 的二进制兼容，以便用户可以平滑地从 CentOS Linux 迁移到 Rocky Linux。
- 社区支持：
- CentOS Linux：CentOS Linux 依赖于社区支持，用户可以通过邮件列表、论坛和社区文档等途径获取帮助。在过去，CentOS 社区一直提供了广泛的支持和资源。
- Rocky Linux：Rocky Linux 同样依赖于社区支持，它的目标是建立一个活跃的社区，提供用户支持和贡献。
总的来说，CentOS Linux 和 Rocky Linux 在目标和理念上非常相似，都致力于提供一个免费、开源的 RHEL 替代方案。主要区别在于起源和维护方面，以及社区的背景和发展。如果你已经在使用 CentOS Linux，Rocky Linux 可能是一个平滑的过渡选择，因为它的设计目标是与 CentOS Linux 8 兼容。无论选择哪个操作系统，都需要评估其社区支持、更新和兼容性等因素，以选择适合你需求的操作系统。
Rocky 8替换k8s节点验证
不管是将centos7升级还是替换为Rocky 8，都要考虑对k8s集群的影响，防止操作将k8s搞崩溃，小编这儿推荐一种做法：
- 验证可行版本的centos后，将其加入k8s集群
- 保证可行版本的centos集群有，etcd、控制面板、worker节点
- 下架以前的老节点