global 集群灾难恢复

Overview

该方案针对 global 集群的灾难恢复场景设计。global 集群作为平台的控制平面,负责管理其他集群。为保证在 global 集群故障时平台服务的持续可用性,本方案部署两个 global 集群:主集群和备用集群。

灾难恢复机制基于主集群到备用集群的 etcd 数据实时同步。当主集群因故障不可用时,服务可快速切换到备用集群。

支持的灾难场景

  • 主集群发生不可恢复的系统级故障,导致无法正常运行;
  • 托管主集群的物理机或虚拟机故障,导致无法访问;
  • 主集群所在位置的网络故障,导致服务中断;

不支持的灾难场景

  • global 集群内部部署的应用故障;
  • 存储系统故障导致的数据丢失(etcd 同步范围之外);

主集群备用集群的角色是相对的:当前为平台提供服务的集群为主集群(DNS 指向该集群),备用集群为备用集群。故障切换后,角色互换。

注意事项

  • 该方案仅同步 global 集群的 etcd 数据,不包含 registry、chartmuseum 或其他组件的数据;

  • 为方便排查和管理,建议节点命名风格如 standby-global-m1,以标明节点所属集群(主集群或备用集群)。

  • 不支持集群内应用数据的灾难恢复;

  • 两个集群间需保持稳定的网络连接,确保 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)及其实例,备用集群必须预先部署相同组件。

流程概述

  1. 准备统一的域名作为平台访问地址;
  2. 将域名指向主集群的 VIP 并安装主集群
  3. 临时切换 DNS 解析至备用 VIP,安装备用集群;
  4. 主集群的 ETCD 加密密钥复制到备用集群后续作为控制平面节点的节点上;
  5. 安装并启用 etcd 同步插件;
  6. 验证同步状态并定期检查;
  7. 发生故障时,将 DNS 切换至备用集群完成灾难恢复。

所需资源

  • 一个统一的域名作为 平台访问地址,以及该域名的 TLS 证书和私钥,用于 HTTPS 服务;

  • 每个集群专用的虚拟 IP 地址——一个用于主集群,另一个用于备用集群;

    • 预先配置负载均衡器,将端口 804436443237911443 的 TCP 流量转发到对应 VIP 后的控制平面节点。

操作步骤

第 1 步:安装主集群

灾难恢复环境安装注意事项

安装灾难恢复环境的主集群时,

  • 首先,记录安装 Web UI 指南中设置的所有参数。安装备用集群时需保持部分选项一致。
  • 必须预配置 User-provisioned 负载均衡器,将流量路由至虚拟 IP。Self-built VIP 选项不可用。
  • 平台访问地址 字段必须填写域名,集群端点 必须填写虚拟 IP 地址。
  • 两个集群必须配置使用 An Existing Certificate(且为同一证书),如有需要请申请合法证书。Self-signed Certificate 选项不可用。
  • 镜像仓库 设置为 Platform Deployment 时,用户名密码 字段均不能为空;IP/域名 字段必须设置为作为 平台访问地址 的域名。
  • 平台访问地址HTTP 端口HTTPS 端口 必须分别为 80 和 443。
  • 安装指南第二页(步骤:高级)中,其他平台访问地址 字段必须包含当前集群的虚拟 IP。

请参考以下文档完成安装:

第 2 步:安装备用集群

  1. 临时将域名指向备用集群的 VIP;

  2. 登录主集群的第一个控制平面节点,将 etcd 加密配置复制到备用集群所有控制平面节点:

    # 假设主集群控制平面节点为 1.1.1.1、2.2.2.2 和 3.3.3.3
    # 备用集群控制平面节点为 4.4.4.4、5.5.5.5 和 6.6.6.6
    for i in 4.4.4.4 5.5.5.5 6.6.6.6  # 替换为备用集群控制平面节点 IP
    do
      ssh "<user>@$i" "sudo mkdir -p /etc/kubernetes/"
      scp /etc/kubernetes/encryption-provider.conf "<user>@$i:/tmp/encryption-provider.conf"
      ssh "<user>@$i" "sudo install -o root -g root -m 600 /tmp/encryption-provider.conf /etc/kubernetes/encryption-provider.conf && rm -f /tmp/encryption-provider.conf"
    done
  3. 按照主集群相同方式安装备用集群

安装备用集群注意事项

安装灾难恢复环境的备用集群时, 以下选项必须与主集群保持一致:

  • 平台访问地址 字段;
  • 证书 的所有字段;
  • 镜像仓库 的所有字段;
  • 重要:确保镜像仓库的凭据和 管理员用户与主集群设置一致。

并且务必遵循第 1 步中的 灾难恢复环境安装注意事项

请参考以下文档完成安装:

第 3 步:启用 etcd 同步

  1. 如适用,配置负载均衡器将端口 2379 转发至对应集群的控制平面节点。仅支持 TCP 模式,不支持 L7 转发。

    INFO

    通过负载均衡器转发端口非必需。 若备用集群可直接访问活动 global 集群,需通过 Active Global Cluster ETCD Endpoints 指定 etcd 地址。

  2. 使用备用 global 集群的 VIP 访问其 Web Console,切换至 Administrator 视图;

  3. 进入 Marketplace > Cluster Plugins,选择 global 集群;

  4. 找到 etcd Synchronizer,点击 Install,配置参数:

    • 若未通过负载均衡器转发端口 2379,需正确配置 Active Global Cluster ETCD Endpoints
    • 使用默认的 Data Check Interval
    • 除非排查问题,否则保持 Print detail logs 关闭。

验证同步 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)'

灾难恢复流程

  1. 如有必要,重启备用集群的 Elasticsearch:

    # 将 installer/res/packaged-scripts/for-upgrade/ensure-asm-template.sh 复制到 /root:
    # 请勿跳过此步骤
    
    # 如有需要,切换至 root 用户
    sudo -i
    
    # 检查 global 集群是否安装了 Elasticsearch 日志存储
    _es_pods=$(kubectl get po -n cpaas-system | grep cpaas-elasticsearch | awk '{print $1}')
    if [[ -n "${_es_pods}" ]]; then
        # 若脚本返回 401 错误,重启 Elasticsearch
        # 然后执行脚本再次检查集群
        bash /root/ensure-asm-template.sh
    
        # 重启 Elasticsearch
        xargs -r -t -- kubectl delete po -n cpaas-system <<< "${_es_pods}"
    fi
  2. 验证备用集群数据一致性(同第 3 步检查);

  3. 卸载 etcd 同步插件;

  4. 取消两个 VIP 上的端口 2379 转发;

  5. 将平台域名 DNS 切换至备用 VIP,该集群即为新的主集群;

  6. 验证 DNS 解析:

    kubectl exec -it -n cpaas-system deployments/sentry -- nslookup <平台访问域>
    # 若解析不正确,重启 coredns Pod 并重试,直至成功
  7. 清理浏览器缓存,访问平台页面确认已切换至原备用集群;

  8. 重启以下服务(如已安装):

    • 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
  9. 若业务集群向主集群发送监控数据,重启业务集群中的 warlock:

    kubectl delete po -n cpaas-system -l service_name=warlock
  10. 在原主集群上重复执行启用 etcd 同步步骤,将其转为新的备用集群。

日常检查

定期检查备用集群的同步状态:

curl $(kubectl get svc -n cpaas-system etcd-sync-monitor -o jsonpath='{.spec.clusterIP}')/check

若发现缺失或多余键,按照输出提示进行处理。

上架软件包

有关 violet push 子命令的详细信息,请参见 Upload Packages