之前使用了helm部署了mongodb,后来这个chart进行了迁移,将其并入了另一个helm
但是上个人不知什么原因,并没有应用mongo的helm工程,反而是单独创建了一个pod和svc用以对外提供服务
现况分析
为了统一使用helm管理,需要将分离出去的mongo服务重新由helm接管,并且由deployment进行创建
网络
旧svc是通过指定pod-template-hash=57cd448d4d的方式进行绑定
helm工程中也由创建svc,但默认情况下helm upgrade不会替换同名的资源,除非指定了force参数
存储
使用了一块10G的pvc,名称是mongodb-pvc
后端连接了一块10G的pv,供应商everest-csi-provisioner,Access Modes是单路可读可写ReadWriteOnce
helm工程
这个chart进行了迁移,chart环境变量变化导致了mongo的deploy的标签选择器内容也变化,但deployment是不允许这样直接修改的,所以这里引起了一个报错——在保证业务连续性的情况下,无法直接通过删除deploy的方式来更换deploy,所以他选择新创建了一个pod来提供服务,作为缓兵之计
也是因为这个问题所以上个人不敢轻易动它
接入deployment
数据备份
方法1:使用kubectl exec到pod内进行备份
这里也分两种
一种是物理备份,就像这样,但是需要停机更新
1 | kubectl --kubeconfig config -n <ns-name>\ |
一种是逻辑备份,也就是使用mongodump
这种方法有个缺点就是直接先备份到pod内,然后通过cp进行复制
也就是对于权限有比较高的要求
如果是和我一样使用的是bitnami的镜像,那么对于权限的控制会非常严格
1 | sudo kubectl --kubeconfig config -n <ns-name> \ |
方法2:使用外部访问端口进行备份(推荐)
1 | #ubuntu 20.04 |
网络与存储替换
本来想改pvc的读写方式的,从单路可读可写改成多路可读可写,然后让新pod去挂载,这样显然更加稳,
当然不出意外的报错了,
因为pvc创建出来之后,除了storage可以修改,其他都无法修改
删除旧pod
删除后,由于pvc不被自动销毁,并且新pod与旧pod的pvc-chaim名称指定皆相同
所以删除旧pod后再删除新pod,新pod重启后自动就挂载了
svc指向新pod
删除原有单独的svc
然后再次应用helm工程,helm upgrade …
svc就被自动创建了