#Global 集群灾难恢复

#概述

此解决方案用于涉及 global 集群的灾难恢复场景。global 集群作为平台的控制平面，负责管理其他集群。为确保 global 集群发生故障时平台服务持续可用，此解决方案会部署两个 global 集群：主集群和备用集群。

灾难恢复机制基于将主集群的 etcd 数据实时同步到备用集群。如果主集群因故障变得不可用，服务可以快速切换到备用集群。

#支持的灾难场景

• 主集群发生不可恢复的系统级故障，导致其无法运行；
• 承载主集群的物理机或虚拟机发生故障，导致主集群无法访问；
• 主集群所在位置发生网络故障，导致服务中断；

#不支持的灾难场景

• global 集群内部所部署的应用发生故障；
• 存储系统故障导致的数据丢失（不在 etcd 同步范围内）；

主集群和备用集群的角色是相对的：当前为平台提供服务的集群是主集群（DNS 指向该集群），另一个集群则是备用集群。故障转移后，这两个角色会互换。

#注意事项

• 此解决方案仅同步 global 集群的 etcd 数据，不包括 registry、chartmuseum 或其他组件的数据；

• 监控和日志数据也不会同步。请勿将业务集群的监控或日志数据存储在主集群或备用集群中：请在专用业务集群中安装用于聚合业务集群数据的 VictoriaMetrics Center 和日志存储，并让每个 global 集群仅收集、存储和查询自身的指标与日志。主集群中的可观测性数据在故障转移后不可用，因此依赖这些数据的备用集群无法观测其刚刚接管的平台；

• 为便于故障排查和管理，建议采用类似 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 切换到备用集群以完成灾难恢复。

#所需资源

• 一个统一域名，该域名将作为 Platform Access Address，以及用于在该域名上提供 HTTPS 服务的 TLS 证书和私钥；

• 每个集群各准备一个专用虚拟 IP 地址——一个用于主集群，另一个用于备用集群；

  • 预先配置负载均衡器，将端口 80、443、6443、2379 和 11443 上的 TCP 流量路由到相应 VIP 后面的控制平面节点。

#操作步骤

#步骤 1：安装主集群

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

• 安装准备
• 安装

#步骤 2：安装备用集群

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

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

   # Assume the primary cluster control plane nodes are 1.1.1.1, 2.2.2.2 & 3.3.3.3
   # and the standby cluster control plane nodes are 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  # Replace with standby cluster control plane node IPs
   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. 按照与主集群相同的方式安装备用集群

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

• 安装准备
• 安装

#步骤 3：启用 etcd 同步

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

   INFO

   无需通过负载均衡器进行端口转发。 如果备用集群可以直接访问活动 global 集群，请通过 Active Global Cluster ETCD Endpoints 指定 etcd 地址。

2. 使用 VIP 访问备用 global 集群 Web Console，并切换到管理员视图；

3. 导航到 Marketplace > Cluster Plugins，选择 global 集群；

4. 找到 Global Cluster Disaster Recovery（对于重命名前发布的软件包，显示为 etcd Synchronizer），点击安装并配置参数：

   • 未通过负载均衡器转发端口 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：仅存在于备用集群中的额外键。从备用集群删除这些键之前，请与运维团队确认。

如果安装了以下组件，请重启其服务：

• Log Storage for Elasticsearch：

  kubectl delete po -n cpaas-system -l service_name=cpaas-elasticsearch

• Advanced Monitoring（原 Monitoring for VictoriaMetrics）：

  kubectl delete po -n cpaas-system -l 'service_name in (alertmanager,vmselect,vminsert)'

#灾难恢复流程

1. 如有必要，重启备用集群上的 Elasticsearch：

   # Copy installer/res/packaged-scripts/for-upgrade/ensure-asm-template.sh to /root:
   # DO NOT skip this step
   
   # switch to the root user if necessary
   sudo -i
   
   # check whether the Log Storage for Elasticsearch is installed on global cluster
   _es_pods=$(kubectl get po -n cpaas-system | grep cpaas-elasticsearch | awk '{print $1}')
   if [[ -n "${_es_pods}" ]]; then
       # In case the script returned the 401 error, restart Elasticsearch
       # then execute the script to check the cluster again
       bash /root/ensure-asm-template.sh
   
       # Restart Elasticsearch
       xargs -r -t -- kubectl delete po -n cpaas-system <<< "${_es_pods}"
   fi

2. 验证备用集群中的数据一致性（检查方式与步骤 3相同）。如果检查报告存在缺失或多余的键，则备用集群与主集群不一致：请勿继续执行下一步。先解决不一致问题或联系技术支持。在两个集群上，还需确认没有处于非运行状态的 Machine 节点，并在继续之前解决此类问题：

   kubectl get machines.platform.tkestack.io

3. 卸载 etcd 同步插件；

4. 移除两个 VIP 上针对 2379 的端口转发；

5. 将平台域名 DNS 切换到备用 VIP，该 VIP 现在成为主集群；

6. 验证 DNS 解析：

   kubectl exec -it -n cpaas-system deployments/sentry -- nslookup <platform access domain>
   # If not resolved correctly, restart coredns Pods and retry until success

7. 清除浏览器缓存并访问平台页面，确认页面反映的是原备用集群；

8. 重启以下服务（如果已安装）：

   • Log Storage for Elasticsearch：

     kubectl delete po -n cpaas-system -l service_name=cpaas-elasticsearch

   • Advanced Monitoring（原 Monitoring for 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 子命令的详细信息，请参阅上架软件包。