Kubernetes跨StorageClass迁移,切换Rainbond默认SC
基于主机安装或基于Kubernetes安装的 Rainbond 集群(均使用默认参数安装),默认使用的共享文件存储是 NFS ,以 Pod 方式运行在 Kubernetes 中,但这种方式也有一些无法避免的问题,比如:NFS 的 SVC 无法通信时集群无法挂载存储则导致不能使用、服务器关机时卡在 umount
导致不能正常关机等等。
当然还有切换共享文件存储的需求,在第一次安装 Rainbond 时,大多数都使用的默认安装,使用一段时间后想切换到外部的 NFS,或者云上的 NAS等等。
在原生的 Kubernetes 集群中,通过 StorageClass 创建的 PVC 是无法修改存储后端的,需要将 PV、PVC 删除后通过新的 StorageClass 创建新的 PVC,然后再将数据迁移,再重新挂载 PVC。当有很多个 PVC 时,需要多次重复的操作。
而 Rainbond 虽然也是通过 StorageClass 创建的 PVC,但相比原生 Kubernetes 省去了创建 PV、PVC 和重新挂载的步骤,以及重复性的操作。在 Rainbond 中只需要将底层存储类更换,然后迁移 Rainbond 所创建的一整个目录,最后重新在页面中修改挂载即可完成迁移。
本文将讲述如何迁移 Rainbond 默认的 NFS 存储到外部 NFS 存储,大致分为以下几个步骤:
- 部署外部 NFS 存储并对接到 K8s 上。
- 备份 NFS 存储的数据。
- 恢复备份数据并切换 Rainbond 默认存储至外部存储。
注意:
- 关闭正在运行的应用,避免增量数据导致数据不一致。
- 组件挂载的存储必须是共享存储,其他存储则需要单独迁移。
部署 NFS 并对接到 K8s 上
外部 NFS 存储可以选择部署 NFS 双机热备或其他方案,这里就不演示了,以单节点 NFS 为例。
在 Centos 上部署 NFS
- 安装
nfs-utils
yum install -y nfs-utils
- 创建共享目录
mkdir -p /data
- 编辑
/etc/exports
文件,添加如下内容:
$ vim /etc/exports /data *(rw,sync,insecure,no_subtree_check,no_root_squash)
- 配置完成后,执行以下命令启动 NFS 服务:
systemctl enable nfs-server systemctl start nfs-server
- 验证 NFS 是否可用
showmount -e 172.20.251.94
在 K8s 中部署 NFS Client
下面将外部的 NFS 存储对接到 Kubernetes 上,在 Kubernetes 中部署 NFS Client Provisioner
-
安装 Helm 命令
-
添加 Helm Chart 仓库
helm repo add rainbond https://openchart.goodrain.com/goodrain/rainbond
- 安装 NFS-Client-Provisioner
helm install nfs-client-provisioner rainbond/nfs-client-provisioner \ --set nfs.server=172.20.251.94 \ --set nfs.path=/data \ --version 1.2.8
- 验证 NFS Client 是否可用,创建 PVC 验证。
$ vim test-pvc.yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: test-claim spec: accessModes: - ReadWriteOnce volumeMode: Filesystem resources: requests: storage: 1Gi storageClassName: nfs-client $ kubectl apply -f test-pvc.yaml
查询 PVC 状态为 Bound 则正常。
备份默认 NFS 的数据
查看 rbd-system
下所有的 PVC。
kubectl get pvc -n rbd-system
PVC名称 | 解释 |
---|---|
data | 测试存储是否正常默认创建的PVC(无用) |
data-nfs-provisioner-0 | NFS Pod所使用的PVC,默认路径在宿主机的/opt/rainbond/data/nfs 下。 |
data-rbd-monitor-0 | 存储监控数据。(可不要) |
rbd-api | 存储 api request 请求日志。(可不要) |
rbd-chaos-cache | 存储构建组件的缓存(可不要) |
rbd-cpt-grdata | 存储平台上所有组件挂载共享存储数据,以及组件的日志。(必须) |
rbd-db-rbd-db-0 | 存储 MySQL 数据,默认是存在本地的,没存储在 NFS 中。 |
rbd-etcd-rbd-etcd-0 | 存储 Etcd 数据,默认是存在本地的,没存储在 NFS 中。 |
rbd-hub | 存储镜像数据(必须) |
以上数据中对于我们要迁移的重要数据有 rbd-cpt-grdata
和 rbd-hub
,根据 VOLUME
名称在默认的存储目录 /opt/rainbond/data/nfs
下查找,例如 pvc-9ec619e3-1e20-4d7a-b744-aa04088fb6c3
。
使用 rsync 同步工具,将数据同步到新的 NFS 存储服务器上,根据以下命令开始同步,根据实际情况修改命令。
rsync -avP /opt/rainbond/data/nfs/pvc-9ec619e3-1e20-4d7a-b744-aa04088fb6c3 root@172.20.251.94:/data rsync -avP /opt/rainbond/data/nfs/pvc-d0bf09ca-5543-4050-bd08-b02ebb593b4e root@172.20.251.94:/data
注意:数据同步完成后切记要校验数据的完整性。
切换 Rainbond 存储
更改 Rainbond 默认存储
- 修改
rainbondcluster
CRD资源,添加storageClassName
$ kubectl edit rainbondcluster -n rbd-system spec: rainbondVolumeSpecRWX: storageClassName: nfs-client #由 NFS-Client-Provisioner 创建的 sc
- 修改
rainbondvolumes
CRD资源,修改storageClassName
为nfs-client
$ kubectl edit rainbondvolumes -n rbd-system spec: storageClassName: nfs-client
- 删除 Rainbond 基于默认 NFS 创建的 StorageClass
rainbondsssc
rainbondslsc
kubectl delete sc rainbondsssc rainbondslsc
- 删除
rbd-system
命名空间下旧的 PVC。这时候会删除不掉,因为还有 POD 在使用该 PVC,先ctrl c
结束。
kubectl delete pvc data data-rbd-monitor-0 rbd-api rbd-chaos-cache rbd-cpt-grdata rbd-hub -n rbd-system
- 删除 Rainbond 组件的控制器让
rainbond-operator
控制 PVC 重新创建。
kubectl delete deploy rbd-api -n rbd-system kubectl delete ds rbd-chaos -n rbd-system kubectl delete sts rbd-monitor -n rbd-system kubectl delete deploy rbd-worker -n rbd-system kubectl delete deploy rbd-hub -n rbd-system kubectl delete deploy rbd-resource-proxy -n rbd-system kubectl delete sts rbd-eventlog -n rbd-system kubectl delete ds rbd-node -n rbd-system
kubectl delete pod -l release=rainbond-operator -n rbd-system
等待所有 POD 重新创建,创建完成后 Rainbond 平台可正常访问,正常工作。
恢复数据
下面将前面备份的数据恢复到新创建的 PVC 中。
此时 rbd-cpt-grdata
和 rbd-hub
新创建的目录下的数据都是自动创建,先将其删除。
rm -rf /data/rbd-system-rbd-cpt-grdata-pvc-44167209-1006-4de5-9801-afcce996449c/* rm -rf /data/rbd-system-rbd-hub-pvc-c326b89f-7c0e-4990-a8e2-31472799ccc8/*
再将备份的 rbd-cpt-grdata
和 rbd-hub
数据分别同步到新的目录中,例如以下命令。
rsync -avP /data/pvc-9ec619e3-1e20-4d7a-b744-aa04088fb6c3/* /data/rbd-system-rbd-cpt-grdata-pvc-44167209-1006-4de5-9801-afcce996449c rsync -avP /data/pvc-d0bf09ca-5543-4050-bd08-b02ebb593b4e /data/rbd-system-rbd-hub-pvc-c326b89f-7c0e-4990-a8e2-31472799ccc8
注意:数据同步完成后切记要校验数据的完整性。
重新 Rainbond 部分组件的 POD 生效。
kubectl delete pod -l name=rbd-api -n rbd-system kubectl delete pod -l name=rbd-chaos -n rbd-system kubectl delete pod -l name=rbd-monitor -n rbd-system kubectl delete pod -l name=rbd-worker -n rbd-system kubectl delete pod -l name=rbd-hub -n rbd-system kubectl delete pod -l name=rbd-resource-proxy -n rbd-system kubectl delete pod -l name=rbd-eventlog -n rbd-system kubectl delete pod -l name=rbd-node -n rbd-system
更改 Rainbond 上的组件存储
替换底层存储后,此时 Rainbond 上组件的存储还未修改,此时需要进入 Rainbond 的组件中将当前存储删除重新添加。
挂载路径、存储类型保持不变,删除当前的配置添加新的同样配置即可。
至此存储切换完成,后续请验证应用的数据是否都完整。
删除默认 NFS 存储资源(可选)
修改 CRD 资源,将 nfs-provisioner
replicas 设置为 0
$ kubectl edit rbdcomponent nfs-provisioner -n rbd-system spec: replicas: 0
删除 nfs-provisioner
控制器
kubectl delete sts nfs-provisioner -n rbd-system
删除 nfs-provisioner 的 PV、PVC
kubectl delete pvc data-nfs-provisioner-0 -n rbd-system kubectl delete pv nfs-provisioner
删除宿主机上的 NFS 数据存储目录
rm -rf /opt/rainbond/data/nfs

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
KMS在腾讯云的微服务实践助力其降本50%
背景介绍 KMS 是一家日本的游戏公司,主要经营游戏业务、数字漫画业务、广告业务、云解决方案业务等,出品了多款在日本畅销的漫画风游戏,同时有网络漫画专业厂牌,以内容创作为目标,拥有原创 IP 创作、游戏开发等多元化发展的业务。 KMS 曾经是微软 Azure 的标杆客户,曾经在 Azure 的 Customer story 里有详细的介绍,主要是使用了 Azure 的 App Service。 2021年,KMS 开始迁移到腾讯云,并把第一款产品部署在了腾讯云上。从 Azure 迁移到腾讯云上后,整体成本降低50%。下面我们就来讲讲他们在腾讯云上的微服务实践。 挑战与痛点 KMS 的架构主要有以下特点: 1. KMS 的架构设计的特点是围绕不同的游戏有不同的终端。 2. 但同时又有统一的后台管理平台、统一的底座等。 3. 客户在游戏场景的不同的客户端主要包括安卓,iOS,Web 等。此外,客户后端又分为战斗系统、管理系统、用户系统等。 4. 游戏业务通常都有波峰波谷,在业务高峰期的时候需要快速扩容来支持大量的游戏玩家;在业务低峰期的时候,需要缩容来节约成本。 那么基于此类场景的架构设计...
- 下一篇
从开源模型到商业落地应用,亚马逊云科技构建实用路线图!
目前生成式 AI 应用落地已经从热火朝天的“百模大战”,步入到了少数优秀模型脱颖而出,工具链百花齐放,以及企业主管认真寻找生成式 AI 落地场景的新阶段。很多都在问:“这个基础模型适合我吗?我能让它更加适应我的领域吗?我该如何创新我的 IT 架构快速构建 AI Native 的应用?怎样衡量引入生成式 AI 的价值?” 基于这一背景,亚马逊云科技特地举办了亚马逊云科技生成式 AI 构建者大会,大会于10月24日下午圆满结束。在本次大会中,众行业大咖和技术专家们深度聚焦生成式 AI 前沿技术,就生成式 AI 的热点技术话题和热门应用场景展开了深入分享与交流,为开发者们解读了当下应如何应对生成式 AI 带来的机遇,在 AI 时代保持强有力的竞争力。 加速大数据与 AI 普惠 亚马逊云科技助力企业构建者释放生成式 AI 潜力 大会开场,亚马逊云科技大中华区产品部总经理陈晓建在以“赋能生成式 AI 新时代,助力数据与 AI 普惠化”为题的主题演讲中指出,生成式 AI 现已成为各行业各组织商业领导者的首要关注点。整个生成式 AI 的应用就像是浮在海面上的冰山,人们常提到的基础模型只是我们能看到的...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2全家桶,快速入门学习开发网站教程
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- 2048小游戏-低调大师作品
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- CentOS7,8上快速安装Gitea,搭建Git服务器
- CentOS6,CentOS7官方镜像安装Oracle11G
- CentOS关闭SELinux安全模块