8.云原生存储之Ceph集群

云原生专栏大纲

文章目录

为什么要用Ceph？glusterfs、ceph、nfs对比使用阿里云nas作为日志存储，多个服务写nas出现日志丢失和混乱k8s将数据文件挂载到nas可能会出现的问题k8s将数据文件挂载到nas并发写问题Ceph 并发写问题（存在瓶颈）

部署前准备os与ceph版本rook与ceph版本ceph与kubenetes版本ceph磁盘要求

境外镜像拉取处理方式1：部署镜像代理服务方式2：导入离线docker镜像

使用Rook安装Ceph集群（常规）部署Admission Controller部署RooK Operator修改cluster.yaml文件创建ceph集群Ceph toolbox 命令行工具暴露dashboard

helm安装ceph集群删除ceph集群（重要）常规部署ceph情况helm部署ceph情况删除Terminating状态命名空间cephcluster无法删除ConfigMap和Secret删除不了处理

通用删除ceph集群方式

Ceph官网文档

为什么要用Ceph？

简单总结：使用nfs作为nas存在并发写和数据一致性问题，ceph提供并发写支持

glusterfs、ceph、nfs对比

特性GlusterFSCephNFS架构分布式文件系统对象存储客户端-服务器模型数据一致性强一致性和弱一致性可配置副本和一致性协议强一致性可扩展性良好的横向扩展性高度可扩展性有限的扩展性性能适用于大文件和顺序访问适用于并发写入和随机访问受限于网络和服务器性能管理复杂性相对简单相对复杂相对简单

GlusterFS、Ceph和NFS（Network File System）都是分布式存储系统，但它们在架构、功能和适用场景上有所不同。下面是对它们进行比较的一些关键方面：

架构：

GlusterFS：采用分布式文件系统的方式，将数据分布在多个存储节点上，通过集中式管理器（glusterd）来管理和协调数据访问。Ceph：采用对象存储的方式，将数据分片并分布在多个存储节点上，通过 CRUSH 算法计算数据位置，并使用 OSD 处理数据存储和访问。NFS：基于客户端-服务器模型，客户端通过网络挂载远程存储服务器上的文件系统，使用标准的文件系统接口进行数据访问。 数据一致性：

GlusterFS：提供强一致性和弱一致性两种模式，可以根据需求进行配置。Ceph：通过副本和一致性协议来保证数据的一致性和可靠性。NFS：提供强一致性，客户端对文件的修改会立即反映到服务器上。 可扩展性：

GlusterFS：具有良好的横向扩展性，可以通过添加存储节点来扩展存储容量和性能。Ceph：具有高度可扩展性，可以通过添加 OSD 和存储节点来扩展存储容量和吞吐量。NFS：不太适合大规模存储集群，扩展性有限。 性能：

GlusterFS：适用于大文件和顺序访问，对小文件和随机访问的性能可能较差。Ceph：具有较好的性能，尤其在并发写入和随机访问方面表现出色。NFS：性能受限于网络和服务器的性能，对小文件和随机访问的性能可能较差。 管理和配置复杂性：

GlusterFS：相对较简单，使用命令行工具或图形界面进行管理和配置。Ceph：相对复杂，需要配置 CRUSH 算法、数据分片策略等，但提供了更高级的管理和配置选项。NFS：相对简单，采用标准的文件系统接口，易于管理和配置。

综合来说，GlusterFS适用于大文件和顺序访问，易于部署和管理；Ceph适用于大规模存储集群，具有高度可扩展性和并发写入能力；NFS适用于简单的文件共享和标准文件系统访问。选择哪个系统取决于具体的需求、数据访问模式和规模。

使用阿里云nas作为日志存储，多个服务写nas出现日志丢失和混乱

使用阿里云 NAS（Network Attached Storage）作为日志存储时，多个服务同时写入 NAS 可能会导致日志丢失和混乱的问题。这是因为 NAS 是一个共享存储设备，多个服务同时写入同一个文件可能会引发以下问题：

写冲突：多个服务同时写入同一个文件可能导致写冲突，其中一个服务的写入可能会覆盖其他服务的写入内容，导致日志丢失或混乱。文件锁定：某个服务正在写入文件时，其他服务可能无法同时写入，需要等待文件解锁。这可能会导致服务之间的延迟和性能问题。

为了避免这些问题，可以考虑以下解决方案：

使用分离的日志文件：每个服务使用独立的日志文件，避免多个服务写入同一个文件。这样可以降低写冲突的风险。使用日志收集工具：将每个服务的日志发送到一个中央日志收集工具，如 Elasticsearch、Fluentd、Logstash 等。这样每个服务可以独立写入自己的日志文件，而中央日志收集工具负责收集和聚合所有日志，并存储到 NAS 或其他存储后端。使用分布式日志系统：使用分布式日志系统如 Apache Kafka、RabbitMQ 等，每个服务将日志写入消息队列中，然后由消费者服务将日志写入 NAS 或其他存储后端。这样可以实现解耦和水平扩展。

无论选择哪种解决方案，都应该注意日志的并发写入和文件锁定问题，以确保日志的完整性和一致性。此外，还应该考虑日志文件的大小和定期归档，以避免单个文件过大导致的性能问题。

k8s将数据文件挂载到nas可能会出现的问题

将数据文件挂载到 Kubernetes 中的 NAS 存储时，可能会遇到以下问题：

性能问题：NAS 存储通常与节点通过网络连接，相对于本地存储，它的性能可能会较低。这可能会影响应用程序的读写性能和响应时间。因此，在将数据文件挂载到 NAS 上时，需要评估 NAS 存储的性能是否满足应用程序的需求。网络稳定性：由于 NAS 存储是通过网络连接的，因此网络的稳定性和延迟可能会对数据访问产生影响。如果网络连接不稳定或延迟较高，可能会导致应用程序对数据的读写操作变慢或超时。并发访问：如果多个 Pod 或节点同时访问 NAS 存储上的同一数据文件，可能会导致并发访问冲突。这可能会引发数据一致性问题或导致文件损坏。在设计应用程序时，需要考虑并发访问的情况，并采取适当的并发控制措施，如使用文件锁定机制或设计合适的数据访问模式。数据保护和备份：NAS 存储通常需要进行数据保护和备份，以防止数据丢失。确保定期备份数据，并采取适当的容灾措施，如使用 RAID 或者跨区域备份，以保护数据免受硬件故障或其他意外事件的影响。

在使用 NAS 存储时，建议进行充分的测试和评估，确保它能满足应用程序的性能、可靠性和数据一致性要求。同时，还可以考虑其他存储选项，如分布式存储系统（如 Ceph、GlusterFS）或云原生存储解决方案（如云提供商的对象存储服务），根据具体需求选择最适合的存储方案。

k8s将数据文件挂载到nas并发写问题

将数据文件挂载到 Kubernetes 中的 NAS 存储时，如果多个 Pod 并发写入同一个文件，可能会出现并发写问题。这种情况下，可能会发生以下问题：

写冲突：多个 Pod 同时写入同一个文件时，写冲突可能会导致数据损坏或丢失。如果多个写操作同时发生，可能会导致文件内容混乱，其中一个写入的内容可能会覆盖其他写入的内容。文件锁定：当一个 Pod 正在写入文件时，其他 Pod 可能无法同时写入，需要等待文件解锁。这可能会导致其他 Pod 的写入延迟和性能下降。

为了避免并发写问题，可以考虑以下解决方案：

使用独立的文件：每个 Pod 使用独立的文件进行写入，避免多个 Pod 写入同一个文件。这样可以降低写冲突的风险。使用文件锁定机制：在访问共享文件时，可以使用文件锁定机制，如 POSIX 文件锁定或分布式锁，以确保只有一个 Pod 可以写入文件。其他 Pod 在写入之前需要等待锁定的释放。使用分布式文件系统：考虑使用分布式文件系统，如 Ceph、GlusterFS 等，这些系统可以提供并发写入的支持，并确保数据一致性。使用分布式日志系统：如果是写入日志文件，可以考虑使用分布式日志系统，如 Elasticsearch、Fluentd、Logstash 等，这些系统可以提供并发写入和聚合日志的功能。

无论选择哪种解决方案，都需要根据实际需求和负载特性进行评估和测试，以确保数据的完整性和一致性，并避免并发写问题导致的数据损坏或丢失。

Ceph 并发写问题（存在瓶颈）

Ceph 的并发写入能力是其设计的一个关键特性，但在实际应用中，也可能会面临一些与并发写入相关的问题。以下是一些可能出现的问题和相应的解决方法：

写入冲突：当多个客户端同时写入相同的对象时，可能会发生写入冲突。这可能导致数据不一致或丢失。

解决方法：可以使用一致性协议（如分布式锁）来保证对同一对象的并发写入的顺序。另外，可以使用版本控制或乐观并发控制机制来处理冲突，以确保数据的一致性。

性能瓶颈：并发写入可能会导致存储集群的性能瓶颈，特别是在写入密集型工作负载下。

解决方法：可以通过增加 OSD 的数量、调整 CRUSH 算法的配置、优化网络带宽和延迟等方式来提高存储集群的性能。另外，可以使用缓存、批处理写入等技术来减轻写入压力。

数据一致性和持久性：并发写入可能会导致数据一致性和持久性方面的挑战。如果写入操作没有正确完成或失败，可能会导致数据丢失或不一致。

解决方法：Ceph 提供了数据副本和故障恢复机制，可以通过配置适当数量的副本来提高数据的冗余和可靠性。此外，可以使用写入确认机制来确保写入操作的完成，并进行适当的错误处理和故障恢复。

网络和带宽限制：并发写入可能会对网络和带宽造成压力，特别是在跨多个节点的分布式存储集群中。

解决方法：可以通过增加网络带宽、优化网络拓扑、使用链路聚合技术等方式来缓解网络和带宽限制。另外，可以使用数据本地化和就近复制等策略来减少跨节点的写入操作。

需要根据具体的应用场景和需求来评估并解决并发写入问题。Ceph 提供了一系列的配置选项和优化策略，可以根据实际情况进行调整和优化，以提供更好的并发写入性能和数据一致性保证。

部署前准备

环境版本系统centos7.5k8sv1.23.10docker20.10.8kubesphere3.3.2rookv1.9.12cephv15.2.17

os与ceph版本

OS Recommendations — Ceph Documentation

A：Ceph 提供了软件包，并对其中的软件进行了全面测试。B：Ceph 提供了软件包，并对其中的软件进行了基本测试。C：Ceph 仅提供软件包。尚未对这些版本进行任何测试。

centos7.x系统ceph版本最好选择Pacific(16.2.z)版本

rook与ceph版本

Ceph Upgrades - Rook Ceph Documentation 选择版本如下图centos7.x系统ceph版本最好选择Pacific(16.2.z)版本，综上rook最好选择v1.9版本

ceph与kubenetes版本

ceph版本k8s版本要求rook v1.12v1.22及以上rook v1.9v1.17及以上

ceph磁盘要求

ceph磁盘要求

原始设备（没有分区或格式化的文件系统）原始分区（没有格式化的文件系统）LVM逻辑卷（没有格式化的文件系统）块模式存储类中可用的持久卷

查看当前磁盘并添加

添加磁盘后查看

境外镜像拉取处理

由于容器镜像均无法正常访问，

推荐安装镜像代理服务，自动使用镜像代理服务拉取新创建的 Pod 中的外网容器镜像（仅限公有镜像）推荐在能访问外网的机器上拉取docker镜像子在离线，该放弃要求较高，需在yaml找到docker镜像版本

方式1：部署镜像代理服务

安装 cert-manager

官方文档： Install cert-manager

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.13.2/cert-manager.yaml

# 代理地址

kubectl apply -f https://ghproxy.com/https://github.com/cert-manager/cert-manager/releases/download/v1.13.2/cert-manager.yaml

安装 registry-proxy

官方网站: https://ketches.cn/registry-proxy/

# 整个命令的作用是从 GitHub 仓库的最新发布版本的重定向 URL 中提取文件名，并将其赋值给名为 LATEST 的环境变量。这样，变量 LATEST 就包含了最新发布版本的文件名，可以在后续的脚本中使用

export LATEST=$(basename $(curl -s -w %{redirect_url} https://github.com/ketches/registry-proxy/releases/latest))

# 打印LATEST -- v1.0.0

echo $LATEST

kubectl apply -f https://raw.githubusercontent.com/ketches/registry-proxy/$LATEST/deploy/manifests.yaml

# 代理地址

kubectl apply -f https://ghproxy.com/https://raw.githubusercontent.com/ketches/registry-proxy/$LATEST/deploy/manifests.yaml

export逐步解释这个命令：

curl -s -w %{redirect_url} https://github.com/ketches/registry-proxy/releases/latest：这部分命令使用 curl 命令从指定的 GitHub 仓库的 /releases/latest 页面获取重定向的 URL。-s 参数表示静默模式，不显示进度或错误信息，-w %{redirect_url} 参数表示输出重定向的 URL。basename：这个命令用于从给定的路径中提取文件名部分。$(…)：这个语法用于执行命令，并将命令的输出结果作为变量的值。

配置

registry-proxy 安装后自动创建 ConfigMap registry-proxy-config，ConfigMap 内容为默认配置，可以通过修改 ConfigMap 来修改默认配置。默认配置如下：

apiVersion: v1

kind: ConfigMap

metadata:

name: registry-proxy-config

namespace: registry-proxy

data:

config.yaml: |

proxies:

docker.io: docker.ketches.cn

registry.k8s.io: k8s.ketches.cn

quay.io: quay.ketches.cn

ghcr.io: ghcr.ketches.cn

gcr.io: gcr.ketches.cn

k8s.gcr.io: k8s-gcr.ketches.cn

docker.cloudsmith.io: cloudsmith.ketches.cn

excludeNamespaces:

- kube-system

- kube-public

- kube-node-lease

includeNamespaces:

- *

默认使用 ketches/cloudflare-registry-proxy 镜像代理服务；默认排除 kube-system、kube-public、kube-node-lease 命名空间下的 Pod 容器镜像代理；修改上述配置实时生效，无需重启 registry-proxy；可以自定义代理地址，例如：docker.io: docker.m.daocloud.io;可以去除代理地址，免去代理；可以增加代理地址，例如：mcr.microsoft.com: mcr.dockerproxy.com；可以通过向 ketches/cloudflare-registry-proxy 项目 提交 Issue 来申请添加新的国外镜像代理服务

方式2：导入离线docker镜像

若不能访问外网，安装过程下载镜像会失败

可以在可以访问外网的机器上下载镜像，或者修改镜像源，以下是rook-v1.13.1版本

docker pull rook/ceph:v1.13.1

docker pull quay.io/cephcsi/cephcsi:v3.10.1

docker pull registry.k8s.io/sig-storage/csi-node-driver-registrar:v2.9.1

docker pull registry.k8s.io/sig-storage/csi-resizer:v1.9.2

docker pull registry.k8s.io/sig-storage/csi-provisioner:v3.6.2

docker pull registry.k8s.io/sig-storage/csi-snapshotter:v6.3.2

docker pull registry.k8s.io/sig-storage/csi-attacher:v4.4.2

docker pull quay.io/ceph/ceph:v18.2.1

将镜像打包成tar

docker save -o D:/ceph.tar registry.k8s.io/sig-storage/csi-node-driver-registrar:v2.8.0 registry.k8s.io/sig-storage/csi-resizer:v1.8.0 registry.k8s.io/sig-storage/csi-provisioner:v3.5.0 registry.k8s.io/sig-storage/csi-snapshotter:v6.2.2 registry.k8s.io/sig-storage/csi-attacher:v4.3.0 k8s.gcr.io/sig-storage/csi-provisioner:v3.0.0 k8s.gcr.io/sig-storage/csi-resizer:v1.3.0 k8s.gcr.io/sig-storage/csi-attacher:v3.3.0 k8s.gcr.io/sig-storage/csi-snapshotter:v4.2.0 k8s.gcr.io/sig-storage/csi-node-driver-registrar:v2.3.0 quay.io/cephcsi/cephcsi:v3.4.0 quay.io/ceph/ceph:v18.2.1

将tar上传到服务器，执行如下命令导入镜像：

小编已经准备好离线安装包RooKOperator.tar，storage-cephcsi.tar

docker load -i ceph.tar

将tar拷贝到其他机器脚本

#!/bin/bash

# 定义要传输的文件和目标路径

file_to_transfer="./storage-cephcsi.tar"

destination_path="/opt"

# 定义远程主机列表

remote_hosts=(

"root@192.168.31.20"

"root@192.168.31.22"

"root@192.168.31.23"

"root@192.168.31.24"

"root@192.168.31.25"

"root@192.168.31.26"

"root@192.168.31.27"

)

# 循环遍历远程主机列表，并执行文件传输

for remote_host in "${remote_hosts[@]}"; do

echo "Transferring file to ${remote_host}..."

scp "${file_to_transfer}" "${remote_host}:${destination_path}"

done

使用Rook安装Ceph集群（常规）

部署Admission Controller

启用Rook准入控制器，以确保使用自定义资源（CR)设置正确配置了Rook。cert-manager.yaml

kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.7.1/cert-manager.yaml

部署RooK Operator

用 Helm 托管安装 Ceph 集群并提供后端存储 · Kubernetes 中文指南——云原生应用架构实战手册

修改operator.yaml

还是operator文件，新版本rook默认关闭了自动发现容器的部署，如果没有指定osd节点的位置，这层配置一定要打开，来让自动发现容器帮助我们去发现设备上的块设备，可以找到ROOK_ENABLE_DISCOVERY_DAEMON改成true即可

下载rook源码：https://github.com/rook/rook，部署RooK Operator

# 进入源码/deploy/examples目录

kubectl apply -f crds.yaml -f common.yaml -f operator.yaml

# 删除部署

kubectl delete -f crds.yaml -f common.yaml -f operator.yaml

# 查看rook Operator是否running

kubectl get pods -n rook-ceph

部署完成内容如下

修改cluster.yaml文件

Linux 命令大全 | 菜鸟教程

查看k8s node

kubectl get node -o wide

放开注释，表明可以在k8s集群之外使用ceph集群

provider: host

设置ceph集群节点和磁盘

# 修改ceph镜像版本关闭更新检查

cephClusterSpec:

cephVersion:

image: quay.io/ceph/ceph:v18.2.1

# 关闭更新检查

cephClusterSpec:

skipUpgradeChecks: true

# dashboard关闭ssl

dashboard:

enabled: true

port: 8443

ssl: false

# 选择自定义挂载卷

storage: # cluster level storage configuration and selection

useAllNodes: false

useAllDevices: false

nodes:

- name: "ksnode20"

devices:

- name: "sdb"

- name: "ksnode24"

devices:

- name: "sdb"

- name: "ksnode25"

devices:

- name: "sdb"

- name: "ksnode26"

devices:

- name: "sdb"

- name: "ksnode27"

devices:

- name: "sdb"

其中nodes下name只能填hostname，不能填写ip地址 device下name为磁盘盘符，新版必须采用裸盘，即未格式化的磁盘。建议最少三个节点，否则后面的试验可能会出现问题

创建ceph集群

创建ceph集群

# 创建ceph集群

kubectl create -f cluster.yaml

# 删除

kubectl delete -f cluster.yaml

# 查看Ceph部署情况

kubectl describe node <节点名称>

# 查看Ceph部署情况

kubectl get pods -n rook-ceph

出现该现象则是存在污点

若cluster.yaml中配置使用到master节点磁盘，则将master污点取消

master节点存在污点，是不允许调度的。取消污点：或者删除 node-role.kubernetes.io/master

查看部署情况

登录kubesphere控制台查看

Ceph toolbox 命令行工具

部署toolbox

# 部署toolbox

kubectl create -f toolbox.yaml -n rook-ceph

# 删除toolbox

kubectl delete -f toolbox.yaml -n rook-ceph

# 查看toolbox部署情况

kubectl get po -n rook-ceph -l app=rook-ceph-tools

验证ceph集群状态

# 进入toolbox容器内部

kubectl -n rook-ceph exec -it deploy/rook-ceph-tools -- bash

bash-4.4$ ceph osd status

ID HOST USED AVAIL WR OPS WR DATA RD OPS RD DATA STATE

0 ksnode25 26.3M 499G 0 0 0 0 exists,up

1 ksnode24 26.8M 499G 0 0 0 0 exists,up

2 ksnode26 26.8M 499G 0 0 0 0 exists,up

3 ksnode27 26.8M 499G 0 0 0 0 exists,up

# 查看ceph磁盘情况

bash-4.4$ ceph df

--- RAW STORAGE ---

CLASS SIZE AVAIL USED RAW USED %RAW USED

hdd 2.0 TiB 2.0 TiB 107 MiB 107 MiB 0

TOTAL 2.0 TiB 2.0 TiB 107 MiB 107 MiB 0

--- POOLS ---

POOL ID PGS STORED OBJECTS USED %USED MAX AVAIL

.mgr 1 1 449 KiB 2 1.3 MiB 0 633 GiB

暴露dashboard

查看内部访问方式

# 查看mgr service

kubectl -n rook-ceph exec -it deploy/rook-ceph-tools -- bash

bash-4.4$ ceph mgr services

{

"dashboard": "https://192.168.31.24:8443/",

"prometheus": "http://192.168.31.24:9283/"

}

内部访问测试

nodeport方式暴露

获取ceph dashboard访问密码

用户名admin 密码获取使用如下命令：

kubectl -n rook-ceph get secret rook-ceph-dashboard-password -o jsonpath="{['data']['password']}" | base64 --decode && echo

登录ceph控制台

rook-ceph-mgr-dashboard服务端口漂移问题

有的版本存在端口漂移问题，测试1.9.12无该问题，1.13.1存在该问题

kubectl get svc rook-ceph-mgr-dashboard -n rook-ceph

发现容器端口漂移从8443漂移到7000，等一会服务nodePort端口会重置关闭

修改port，重新部署

helm安装ceph集群

参考：k8s部署rook-ceph记录_k8s安装rook-ceph1.10

先安装rook-operator , 运行正常后安装rook-cluster添加应用仓库：https://charts.rook.io/release

从应用仓库中安装ceph

修改vlues.yml该配置参考cluster.yaml配置文件，主要修改内容如下：

# 修改ceph镜像版本关闭更新检查

cephClusterSpec:

cephVersion:

image: quay.io/ceph/ceph:v18.2.1

# 关闭更新检查

cephClusterSpec:

skipUpgradeChecks: true

# dashboard关闭ssl

dashboard:

enabled: true

port: 8443

ssl: false

# 选择自定义挂载卷

storage: # cluster level storage configuration and selection

useAllNodes: false

useAllDevices: false

nodes:

- name: "node180"

devices: # specific devices to use for storage can be specified for each node

- name: "sdc"

- name: "node181"

devices:

- name: "sdc"

- name: "node182"

devices:

- name: "sdc"

开启其他功能（可选）Ceph Docs

删除ceph集群（重要）

在搭建过程存在反复搭建删除的情况，删除集群存在很多坑，这儿小编特别说明，删除小编参考kubernetes上的分布式存储集群搭建(Rook/ceph)

常规部署ceph情况

常规部署ceph情况，执行下述命令即可删除

kubectl delete -f cluster.yaml

kubectl delete -f crds.yaml -f common.yaml -f operator.yaml

helm部署ceph情况

小编通过下述命令先部署了operator

kubectl apply -f crds.yaml -f common.yaml -f operator.yaml

小编在kubesphere应用仓库部署了上诉在应用仓库部署ceph相当于

kubectl create -f cluster.yaml

部署过程没有问题，当小编想删除ceph时

小编直接在应用删除了ceph应用

该操作不等价kubectl delete -f cluster.yaml ，资源没有被删除，此时小编直接在kubesphere控制台删除了rook-ceph项目，出现现象rook-ceph命名空间一直处于Terminating，rook-ceph命名空间删除后，该空间下的ConfigMap资源rook-ceph-mon-endpoints和Secret资源rook-ceph-mon删除不了

删除Terminating状态命名空间

查看命名空间下是否还存在资源没删除干净

kubectl api-resources -o name --verbs=list --namespaced | xargs -n 1 kubectl get --show-kind --ignore-not-found -n <命名空间>

若存在着删除

kubectl api-resources -o name --verbs=list --namespaced | xargs -n 1 kubectl delete --ignore-not-found --all -n <命名空间>

强制删除命名空间

kubectl delete namespace <命名空间> --grace-period=0 --force

大多数情况下，命名空间下的资源无法强制删除，您可以使用原生接口进行删除

kubectl get ns <命名空间> -o json > <命名空间>.json

# 删除json文件下述内容：

"spec": {

"finalizers": [

"kubernetes"

]

},

开启代理接口

[root@ksmaster21 opt]# kubectl proxy

Starting to serve on 127.0.0.1:8001

调用接口删除namespace，注意修改要删除的<命名空间>

curl -k -H "Content-Type: application/json" -X PUT --data-binary @<命名空间>.json http://127.0.0.1:8001/api/v1/<命名空间>/rook-ceph/finalize

cephcluster无法删除

# 查看cephcluster

kubectl -n rook-ceph get cephcluster

# 查看资源

kubectl api-resources --namespaced=true -o name|xargs -n 1 kubectl get --show-kind --ignore-not-found -n rook-ceph

# 编辑资源，进行删除

kubectl edit cephcluster.ceph.rook.io -n rook-ceph

# 把finalizers的值删掉，cephcluster.ceph.rook.io便会自己删除

ConfigMap和Secret删除不了处理

当您尝试删除 Kubernetes 命名空间时，如果出现错误消息 “Some content in the namespace has finalizers remaining”，并且提到了特定的 finalizer（例如 ceph.rook.io/disaster-protection），这意味着该命名空间中的某些资源仍然具有未删除的 finalizer。Finalizers 是 Kubernetes 中用于确保资源在删除过程中执行特定逻辑的机制。如果资源具有 finalizer，Kubernetes 将阻止删除该资源，直到 finalizer 的逻辑完成。

确定具有 finalizers 的资源：使用以下命令查找具有 finalizers 的资源

安装jq工具

sudo yum install epel-release

sudo yum install jq

# 确定具有 finalizers 的资源

kubectl get -n -o json | jq '.items[] | select(.metadata.finalizers!=null) | .metadata.name'

将 替换为具有 finalizers 的资源类型（例如 Deployment、StatefulSet、Pod 等），将 替换为命名空间名称

删除 finalizers：对于每个具有 finalizers 的资源，您可以使用以下命令删除 finalizers

kubectl patch -n -p '{"metadata":{"finalizers":[]}}' --type=merge

将 替换为具有 finalizers 的资源类型，将 替换为资源名称，将 替换为命名空间名称

通用删除ceph集群方式

删除Cephcluster CRD

kubectl -n rook-ceph delete cephcluster rook-ceph

# 确实是否删除

kubectl -n rook-ceph get cephcluster

删除Operator 和相关的资源

kubectl delete -f operator.yaml

kubectl delete -f common.yaml

kubectl delete -f crds.yaml

删除主机上的数据

rook创建cluster的时候会把部分数据卸载本机的/var/lib/rook(dataDirHostPath指定的目录)中，如果不删除会影响下次集群部署，rook据说下个版本会增加k8s 本地存储调用的功能，就不会直接存在硬盘上了

rm -rf /var/lib/rook

擦除硬盘上的数据

创建osd时被写入了数据，需要擦除，否则无法再次创建ceph集群，脚本中有各种硬盘的擦除命令，不需要全部执行成功，根据当前机器的硬盘情况确定。安装依赖组件

sudo yum install gdisk

执行如下脚本：

#!/usr/bin/env bash

# 定义了一个变量 DISK，表示要进行清理的磁盘设备路径

DISK="/dev/sdb"

# 使用 sgdisk 命令对指定的磁盘设备进行全盘擦除，将磁盘分区表和分区信息清除

sgdisk --zap-all $DISK

# 使用 dd 命令将 /dev/zero 的内容写入指定的磁盘设备，以清除设备上的数据。bs=1M 指定每次写入的块大小为 1MB，count=100 指定写入 100 个块。oflag=direct,dsync 用于将数据直接写入设备并确保数据同步到物理设备上

dd if=/dev/zero of="$DISK" bs=1M count=100 oflag=direct,dsync

# 使用 blkdiscard 命令对指定的磁盘设备进行块丢弃操作，将设备上的数据块标记为可回收状态

blkdiscard $DISK

# 列出以 /dev/mapper/ceph- 开头的设备映射，并使用 dmsetup 命令逐个移除这些设备映射

ls /dev/mapper/ceph-* | xargs -I% -- dmsetup remove %

# 递归删除以 /dev/ceph- 开头的设备节点

rm -rf /dev/ceph-*

# 递归删除以 /dev/mapper/ceph-- 开头的设备映射节点

rm -rf /dev/mapper/ceph--*

这个脚本的目的是清理 Ceph 存储集群相关的设备和映射，以便重新配置或删除 Ceph 存储集群。请注意，运行此脚本将会清除指定磁盘上的数据，因此在运行之前，请确保您已经备份了重要的数据，并且明确了脚本中 DISK 变量指定的磁盘设备是正确的。

推荐链接

 您阅读本篇文章共花了：