1. 私有云实战之基础环境搭建
2. 云原生实战之kubesphere搭建
3.云原生之kubesphere运维
4. 云原生之kubesphere基础服务搭建
5.云原生安全之kubesphere应用网关配置域名TLS证书
6.云原生之DevOps和CICD
7.云原生之jenkins集成SonarQube
8.云原生存储之Ceph集群
文章目录
- 为什么要用Ceph?
-
- glusterfs、ceph、nfs对比
- 使用阿里云nas作为日志存储,多个服务写nas出现日志丢失和混乱
- k8s将数据文件挂载到nas可能会出现的问题
- k8s将数据文件挂载到nas并发写问题
- [Ceph 并发写问题(存在瓶颈)](#Ceph 并发写问题(存在瓶颈))
- 部署前准备
- 境外镜像拉取处理
- 使用Rook安装Ceph集群(常规)
-
- [部署Admission Controller](#部署Admission Controller)
- [部署RooK Operator](#部署RooK Operator)
- 修改cluster.yaml文件
- 创建ceph集群
- [Ceph toolbox 命令行工具](#Ceph toolbox 命令行工具)
- 暴露dashboard
- helm安装ceph集群
- 删除ceph集群(重要)
为什么要用Ceph?
简单总结:使用nfs作为nas存在并发写和数据一致性问题,ceph提供并发写支持
glusterfs、ceph、nfs对比
特性 | GlusterFS | Ceph | NFS |
---|---|---|---|
架构 | 分布式文件系统 | 对象存储 | 客户端-服务器模型 |
数据一致性 | 强一致性和弱一致性可配置 | 副本和一致性协议 | 强一致性 |
可扩展性 | 良好的横向扩展性 | 高度可扩展性 | 有限的扩展性 |
性能 | 适用于大文件和顺序访问 | 适用于并发写入和随机访问 | 受限于网络和服务器性能 |
管理复杂性 | 相对简单 | 相对复杂 | 相对简单 |
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.5 |
k8s | v1.23.10 |
docker | 20.10.8 |
kubesphere | 3.3.2 |
rook | v1.9.12 |
ceph | v15.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.12 | v1.22及以上 |
rook v1.9 | v1.17及以上 |
ceph磁盘要求
- ceph磁盘要求
- 原始设备(没有分区或格式化的文件系统)
- 原始分区(没有格式化的文件系统)
- LVM逻辑卷(没有格式化的文件系统)
- 块模式存储类中可用的持久卷
- 查看当前磁盘并添加
- 添加磁盘后查看
境外镜像拉取处理
由于容器镜像均无法正常访问,
- 推荐安装镜像代理服务,自动使用镜像代理服务拉取新创建的 Pod 中的外网容器镜像(仅限公有镜像)
- 推荐在能访问外网的机器上拉取docker镜像子在离线,该放弃要求较高,需在yaml找到docker镜像版本
方式1:部署镜像代理服务
- 安装 cert-manager
官方文档: Install cert-manager
java
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/
java
# 整个命令的作用是从 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 来修改默认配置。默认配置如下:
java
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版本
java
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
docker save -o D:/rook-1.13.1.tar rook/ceph:v1.13.1 quay.io/cephcsi/cephcsi:v3.10.1 registry.k8s.io/sig-storage/csi-node-driver-registrar:v2.9.1 registry.k8s.io/sig-storage/csi-resizer:v1.9.2 registry.k8s.io/sig-storage/csi-provisioner:v3.6.2 registry.k8s.io/sig-storage/csi-snapshotter:v6.3.2 registry.k8s.io/sig-storage/csi-attacher:v4.4.2
- 将镜像打包成tar
java
docker save -o D:/RooKOperator.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
docker save -o D:/storage-cephcsi.tar 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
docker save -o D:/toolbox.tar quay.io/ceph/ceph:v18.2.1
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
# 删除镜像
docker rmi 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
bash
docker load -i ceph.tar
- 将tar拷贝到其他机器脚本
bash
#!/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
bash
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
java
# 进入源码/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文件
- 查看k8s node
java
kubectl get node -o wide
- 放开注释,表明可以在k8s集群之外使用ceph集群
java
provider: host
- 设置ceph集群节点和磁盘
java
# 修改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集群
java
# 创建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
basic
# 部署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集群状态
java
# 进入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
- 查看内部访问方式
bash
# 查看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 密码获取使用如下命令:
java
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存在该问题
bash
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配置文件,主要修改内容如下:
basic
# 修改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情况,执行下述命令即可删除
java
kubectl delete -f cluster.yaml
kubectl delete -f crds.yaml -f common.yaml -f operator.yaml
helm部署ceph情况
小编通过下述命令先部署了operator
java
kubectl apply -f crds.yaml -f common.yaml -f operator.yaml
小编在kubesphere应用仓库部署了
上诉在应用仓库部署ceph相当于
java
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状态命名空间
- 查看命名空间下是否还存在资源没删除干净
java
kubectl api-resources -o name --verbs=list --namespaced | xargs -n 1 kubectl get --show-kind --ignore-not-found -n <命名空间>
- 若存在着删除
java
kubectl api-resources -o name --verbs=list --namespaced | xargs -n 1 kubectl delete --ignore-not-found --all -n <命名空间>
- 强制删除命名空间
java
kubectl delete namespace <命名空间> --grace-period=0 --force
- 大多数情况下,命名空间下的资源无法强制删除,您可以使用原生接口进行删除
java
kubectl get ns <命名空间> -o json > <命名空间>.json
# 删除json文件下述内容:
"spec": {
"finalizers": [
"kubernetes"
]
},
- 开启代理接口
java
[root@ksmaster21 opt]# kubectl proxy
Starting to serve on 127.0.0.1:8001
- 调用接口删除namespace,注意修改要删除的<命名空间>
java
curl -k -H "Content-Type: application/json" -X PUT --data-binary @<命名空间>.json http://127.0.0.1:8001/api/v1/<命名空间>/rook-ceph/finalize
cephcluster无法删除
java
# 查看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 的资源
java
安装jq工具
sudo yum install epel-release
sudo yum install jq
# 确定具有 finalizers 的资源
kubectl get <resource-type> -n <namespace> -o json | jq '.items[] | select(.metadata.finalizers!=null) | .metadata.name'
将 替换为具有 finalizers 的资源类型(例如 Deployment、StatefulSet、Pod 等),将 替换为命名空间名称
- 删除 finalizers:对于每个具有 finalizers 的资源,您可以使用以下命令删除 finalizers
java
kubectl patch <resource-type> <resource-name> -n <namespace> -p '{"metadata":{"finalizers":[]}}' --type=merge
将 替换为具有 finalizers 的资源类型,将 替换为资源名称,将 替换为命名空间名称
通用删除ceph集群方式
- 删除Cephcluster CRD
java
kubectl -n rook-ceph delete cephcluster rook-ceph
# 确实是否删除
kubectl -n rook-ceph get cephcluster
- 删除Operator 和相关的资源
java
kubectl delete -f operator.yaml
kubectl delete -f common.yaml
kubectl delete -f crds.yaml
- 删除主机上的数据
rook创建cluster的时候会把部分数据卸载本机的/var/lib/rook(dataDirHostPath指定的目录)中,如果不删除会影响下次集群部署,rook据说下个版本会增加k8s 本地存储调用的功能,就不会直接存在硬盘上了
java
rm -rf /var/lib/rook
- 擦除硬盘上的数据
创建osd时被写入了数据,需要擦除,否则无法再次创建ceph集群,脚本中有各种硬盘的擦除命令,不需要全部执行成功,根据当前机器的硬盘情况确定。
安装依赖组件
java
sudo yum install gdisk
执行如下脚本:
java
#!/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 变量指定的磁盘设备是正确的。