#global 集群容灾

#概述

本方案专为 global 集群的容灾场景设计。global 集群作为平台的控制平面，负责管理其他集群。为确保在 global 集群发生故障时平台服务持续可用，本方案部署两个 global 集群：主集群（Primary Cluster）和备集群（Standby Cluster）。

容灾机制基于将主集群的 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 Synchronizer；
6. 验证同步状态并执行定期检查；
7. 发生故障时，将 DNS 切换到备集群以完成容灾。

#所需资源

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

#网络要求

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

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

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

网络策略必须是双向的，因为故障切换后集群角色会互换。故障切换前，有效的服务流量通常是从备集群到主集群。故障切换后，原主集群成为新的备集群，必须能够通过相同端口访问新的主集群。此要求并不会使 etcd 复制变为双向： etcd Synchronizer 仅在当前备集群上运行，并将同步的数据写入其本地 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. 在适用的情况下，配置负载均衡器将端口 2379 转发到相应集群的控制平面节点。仅支持 TCP 模式；不支持 L7 转发。

   INFO

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

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

3. 导航至 Marketplace > 集群插件，选择 global 集群。

4. 找到 etcd Synchronizer，点击安装，并配置以下参数：

   4.3.1+

   4.3.0

   前提条件（仅 4.3.1+）： 在备 global 集群上创建 etcd-sync-active-cluster-token Secret。首先，从活动的 global 集群获取用于访问其 API server 的 bearer 令牌。然后复制命令输出，并在创建 Secret 时使用。该 Secret 将令牌存储在 data 键 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 -

   • 将 Active Global Cluster VIP 设置为活动 global 集群的 VIP。
   • 当不通过负载均衡器转发端口 2379 时，请正确配置 Active Global Cluster ETCD Endpoints。
   • 将 Standby Cluster ETCD Endpoints 设置为备集群 etcd 地址。除非本地 etcd 服务通过不同的端点暴露，否则使用默认值。
   • 将 Active Global Cluster Token Secret 设置为 etcd-sync-active-cluster-token。
   • Data Check Interval 使用默认值。
   • 除非进行故障排查，否则保持 Print detail logs 为禁用状态。

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

   验证 bootstrap 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

   • 当不通过负载均衡器转发端口 2379 时，请正确配置 Active Global Cluster ETCD Endpoints。
   • Data Check Interval 使用默认值。
   • 除非进行故障排查，否则保持 Print detail logs 为禁用状态。

请等待 kubectl get lease -n cpaas-system etcd-sync-mirror -o jsonpath='{.spec.holderIdentity}' 返回非空值后再继续。

验证备集群上的同步 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：键存在于主 global 集群中，但备集群中缺失。重启当前 etcd-sync leader Pod 后通常可以解决。
• LOCAL ETCD surplus keys：键存在于备 global 集群中，但不存在于主集群中。删除前请与运维团队一起审查这些键。

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

• Log Storage for Elasticsearch：

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

• 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 中的检查相同）。如果检查报告存在缺失或多余的键，则备集群与主集群不一致：请勿继续下一步。请先解决不一致问题或联系技术支持。同时在两个集群上确认没有处于非 running 状态的 Machine 节点，并在继续之前解决这些问题：

   kubectl get machines.platform.tkestack.io

3. 卸载 etcd Synchronizer；

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. 重启以下服务（如果已安装）：

   • Log Storage for Elasticsearch：

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

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