global 集群灾难恢复
目录
Overview
该方案针对 global
集群的灾难恢复场景设计。global
集群作为平台的控制平面,负责管理其他集群。为确保 global
集群故障时平台服务的持续可用性,本方案部署两个 global
集群:主集群和备用集群。
灾难恢复机制基于主集群到备用集群的 etcd 数据实时同步。当主集群因故障不可用时,服务可快速切换至备用集群。
支持的灾难场景
- 主集群发生不可恢复的系统级故障,导致无法正常运行;
- 托管主集群的物理或虚拟机故障,导致无法访问;
- 主集群所在位置网络故障,造成服务中断;
不支持的灾难场景
global
集群内部部署的应用故障;
- 存储系统故障导致的数据丢失(超出 etcd 同步范围);
主集群和备用集群的角色是相对的:当前对外提供平台服务的集群为主集群(DNS 指向该集群),备用集群为备用集群。故障切换后,角色互换。
注意事项
-
本方案仅同步 global
集群的 etcd 数据;不包含 registry、chartmuseum 等组件的数据;
-
不支持集群内应用数据的灾难恢复;
-
两集群间需保持稳定网络连接,确保 etcd 同步可靠;
-
若集群基于异构架构(如 x86 与 ARM),需使用双架构安装包;
-
以下命名空间不参与 etcd 同步。如在这些命名空间创建资源,需用户自行备份:
cpaas-system
cert-manager
default
global-credentials
cpaas-system-global-credentials
kube-ovn
kube-public
kube-system
nsx-system
cpaas-solution
kube-node-lease
kubevirt
nativestor-system
operators
-
若两个集群均使用内置镜像仓库,需分别上传镜像包;
-
若主集群部署了 DevOps Eventing v3(knative-operator)及其实例,备用集群需预先部署相同组件。
流程概述
- 准备统一的域名作为平台访问入口;
- 将域名指向主集群 VIP 并安装主集群;
- 临时将 DNS 解析切换至备用 VIP,安装备用集群;
- 安装并启用 etcd 同步插件;
- 验证同步状态并定期检查;
- 发生故障时,将 DNS 切换至备用集群完成灾难恢复。
所需资源
-
一个域名,作为平台访问入口;
-
两个 VIP,分别对应主集群和备用集群;
- 两个 VIP 均需转发 TCP 端口
80
、443
、6443
、2379
和 11443
到集群的三个控制平面节点。
详细流程
第 1 步:安装主集群
参考以下文档完成安装:
配置说明:
- 在“Other Platform Access Addresses”中添加集群 VIP;
- 平台访问地址必须使用统一域名。
第 2 步:安装备用集群
- 临时将域名指向备用集群 VIP;
- 登录主集群第一个主节点,将 etcd 加密配置复制到所有备用集群主节点:
for i in 1.1.1.1 2.2.2.2 3.3.3.3 # 替换为备用集群控制平面节点 IP
do
ssh $i "mkdir -p /etc/kubernetes/"
scp /etc/kubernetes/encryption-provider.conf $i:/etc/kubernetes/encryption-provider.conf
done
- 按照与主集群相同方式安装备用集群,参考:
配置说明:
- 使用与主集群相同的域名和证书;
- 使用相同的镜像仓库及凭证;
- 在“Other Platform Access Addresses”中添加备用集群 VIP。
第 3 步:启用 etcd 同步
-
确保端口 2379
已正确转发至两个集群的控制平面节点;
-
使用备用 global 集群 VIP 登录 Web 控制台,切换至 Administrator 视图;
-
进入 Marketplace > Cluster Plugins,选择 global
集群;
-
找到 etcd Synchronizer,点击 Install,配置参数:
- 使用默认同步间隔;
- 日志开关默认关闭,除非排查问题时开启。
确认同步 Pod 在备用集群运行:
kubectl get po -n cpaas-system -l app=etcd-sync
kubectl logs -n cpaas-system $(kubectl get po -n cpaas-system -l app=etcd-sync --no-headers | head -1) | grep -i "Start Sync update"
出现 “Start Sync update” 后,重建其中一个 Pod 以重新触发带有 ownerReference 依赖的资源同步:
kubectl delete po -n cpaas-system $(kubectl get po -n cpaas-system -l app=etcd-sync --no-headers | head -1)
检查同步状态:
mirror_svc=$(kubectl get svc -n cpaas-system etcd-sync-monitor -o jsonpath='{.spec.clusterIP}')
ipv6_regex="^[0-9a-fA-F:]+$"
if [[ $mirror_svc =~ $ipv6_regex ]]; then
export mirror_new_svc="[$mirror_svc]"
else
export mirror_new_svc=$mirror_svc
fi
curl $mirror_new_svc/check
输出说明:
LOCAL ETCD missed keys
:主集群存在但备用集群缺失的键,通常因同步时资源顺序导致 GC。重启一个 etcd-sync Pod 可修复;
LOCAL ETCD surplus keys
:备用集群独有的多余键,删除前请与运维确认。
若安装以下组件,重启其服务:
-
Elasticsearch 日志存储:
kubectl delete po -n cpaas-system -l service_name=cpaas-elasticsearch
-
VictoriaMetrics 监控:
kubectl delete po -n cpaas-system -l 'service_name in (alertmanager,vmselect,vminsert)'
灾难恢复流程
- 若安装了 Elasticsearch 日志存储,在备用集群执行:
# 复制 installer/res/packaged-scripts/for-upgrade/ensure-asm-template.sh 至 /root 并执行:
bash /root/ensure-asm-template.sh
# 若返回 401,重启 Elasticsearch 并重试
- 验证备用集群数据一致性(同第 Step 3 检查);
- 卸载 etcd 同步插件;
- 取消两个 VIP 的
2379
端口转发;
- 将平台域名 DNS 切换至备用 VIP,该集群成为新的主集群;
- 验证 DNS 解析:
kubectl exec -it -n cpaas-system deployments/sentry -- nslookup <platform access domain>
# 若解析异常,重启 coredns Pod 并重试,直至成功
- 清理浏览器缓存,访问平台页面,确认为原备用集群;
- 重启以下服务(如已安装):
-
Elasticsearch 日志存储:
kubectl delete po -n cpaas-system -l service_name=cpaas-elasticsearch
-
VictoriaMetrics 监控:
kubectl delete po -n cpaas-system -l 'service_name in (alertmanager,vmselect,vminsert)'
-
cluster-transformer:
kubectl delete po -n cpaas-system -l service_name=cluster-transformer
- 若业务集群向主集群发送监控数据,重启业务集群中的 warlock:
kubectl delete po -n cpaas-system -l service_name=warlock
- 在原主集群重复执行 启用 etcd 同步 步骤,将其转为新的备用集群。
日常检查
定期在备用集群检查同步状态:
curl $(kubectl get svc -n cpaas-system etcd-sync-monitor -o jsonpath='{.spec.clusterIP}')/check
若发现缺失或多余键,按输出提示处理。