#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. 安装并启用 Global Cluster Disaster Recovery；
6. 验证同步状态并定期检查；
7. 发生故障时，将 DNS 切换到备用集群以完成灾难恢复。

#所需资源

• 一个统一域名，该域名将作为 Platform Access Address，以及用于在该域名上提供 HTTPS 服务的 TLS 证书和私钥；
• 每个集群各需一个专用虚拟 IP 地址——一个用于主集群，另一个用于备用集群；

#网络要求

统一域名是灾难恢复的前提条件。正常运行期间，该域名仅解析到主集群 VIP。备用集群使用该域名访问主集群上的平台服务。

安装任一集群之前，请完成以下两项网络准备：

• 配置每个集群的负载均衡器，将 VIP 上所需的 TCP 端口转发到该 VIP 后端的控制平面节点。仅当用户通过 HTTP 访问平台时，才配置端口 80。
• 在主集群和备用集群的网络之间，双向开放所需的 TCP 端口。将规则应用于防火墙、安全组、路由器 ACL 以及任何其他站点间网络控制措施。

网络策略必须是双向的，因为故障转移后集群角色会互换。故障转移前，实际服务流量通常从备用集群流向主集群。故障转移后，原主集群成为新的备用集群，必须通过相同端口访问新的主集群。这项要求并不意味着 etcd 复制是双向的： Global Cluster Disaster Recovery 仅在当前备用集群上运行，并将同步的数据写入其本地 etcd。

#操作步骤

#步骤 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. 安装插件之前，从活动 global 集群获取用于访问其 API server 的 bearer token。复制命令输出，并在备用 global 集群的 cpaas-system 命名空间中创建 etcd-sync-active-cluster-token Secret 时使用该输出。该 Secret 使用数据键 token 存储令牌。

   # Run this command on the active cluster.
   kubectl -n cpaas-system get secret k8sadmin -o jsonpath='{.data.token}' | base64 -d

   复制输出值，然后在备用集群上运行此命令：

   ACTIVE_CLUSTER_TOKEN='<paste-the-token-from-the-active-cluster>'
   kubectl -n cpaas-system create secret generic etcd-sync-active-cluster-token \
     --from-literal=token="${ACTIVE_CLUSTER_TOKEN}" \
     --dry-run=client -o yaml | kubectl apply -f -

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

   INFO

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

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

4. 转到 Marketplace > Cluster Plugins，选择 global 集群。

5. 找到 Global Cluster Disaster Recovery，单击安装，并配置以下参数：

   • 将活动 Global 集群 VIP设置为活动 global 集群的 VIP。
   • 如果未通过负载均衡器转发端口 2379，请正确配置活动 Global 集群 ETCD 端点。
   • 将备用集群 ETCD 端点设置为备用集群的 etcd 地址。除非本地 etcd 服务通过其他端点公开，否则请使用默认值。
   • 将活动 Global 集群令牌 Secret设置为 etcd-sync-active-cluster-token。
   • 数据检查间隔使用默认值。
   • 除非正在排查问题，否则请保持禁用打印详细日志。

安装期间，系统会先运行 etcd-sync-bootstrap Job，然后启动 etcd-sync Deployment。Job 准备好 remote-etcd-ca、remote-etcd-issuer 和 remote-etcd-client 后，插件安装才会继续。

验证引导 Job 和运行时资源：

kubectl get job -n cpaas-system etcd-sync-bootstrap
kubectl logs -n cpaas-system job/etcd-sync-bootstrap
kubectl get secret -n cpaas-system remote-etcd-ca
kubectl get issuer -n cpaas-system remote-etcd-issuer
kubectl get certificate -n cpaas-system remote-etcd-client
kubectl get secret -n cpaas-system remote-etcd-client

验证同步 Pod 在备用集群上运行，并确定当前 leader：

kubectl get po -n cpaas-system -l app=etcd-sync
kubectl get lease -n cpaas-system etcd-sync-mirror
leader_pod=$(kubectl get lease -n cpaas-system etcd-sync-mirror -o jsonpath='{.spec.holderIdentity}')
kubectl logs -n cpaas-system "$leader_pod" | grep -E "Acquired leader lease|Start Sync update"

如果需要重新同步具有 ownerReference 依赖关系的资源，请在 Start Sync update 出现后重新创建当前 leader Pod：

leader_pod=$(kubectl get lease -n cpaas-system etcd-sync-mirror -o jsonpath='{.spec.holderIdentity}')
kubectl delete po -n cpaas-system "$leader_pod"

检查同步状态：

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
  mirror_host="[$mirror_svc]"
else
  mirror_host="$mirror_svc"
fi
curl -g "http://${mirror_host}/check"

输出说明：

• LOCAL ETCD missed keys：主集群中存在但备用集群中缺失的键。通常是由于同步期间资源顺序导致 GC 引起的。重启当前 etcd-sync leader Pod 可解决此问题；
• LOCAL ETCD surplus keys：仅存在于备用集群中的额外键。删除这些键之前，请先与运维团队确认。

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

• Elasticsearch 日志存储：

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

• 高级监控：

  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. 卸载 Global Cluster Disaster Recovery；

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

5. 将平台域名 DNS 切换到备用 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. 重启以下服务（如果已安装）：

   • Elasticsearch 日志存储：

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

   • 高级监控：

     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 同步的步骤，将其转换为新的备用集群。

#例行检查

定期在备用集群上检查同步状态：

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
  mirror_host="[$mirror_svc]"
else
  mirror_host="$mirror_svc"
fi
curl -g "http://${mirror_host}/check"

如果存在缺失或多余的键，请按照输出中的说明解决。

#上架软件包

有关 violet push 子命令的详细信息，请参阅上架软件包。