Global 集群灾难恢复

灾难恢复路径

本页面介绍运行在传统操作系统上的 global 集群的灾难恢复。Immutable Infrastructure 上的 global 集群灾难恢复功能正在开发中；请参阅 Immutable Infrastructure 上的 Global 集群灾难恢复。

NOTE

从 ACP 4.5 开始， etcd Synchronizer 更名为 Global 集群灾难恢复。从 customer portal 下载插件时，请搜索 Global 集群灾难恢复。重命名之前发布的插件软件包在上传后，平台中仍会显示 etcd Synchronizer。

概述

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

灾难恢复机制基于将 Primary Cluster 中的 etcd 数据实时同步到 Standby Cluster。如果 Primary Cluster 因故障而不可用，服务可以快速切换到 Standby Cluster。

支持的灾难场景

Primary Cluster 发生不可恢复的系统级故障，导致其无法运行；
托管 Primary Cluster 的物理机或虚拟机发生故障，导致其无法访问；
Primary Cluster 所在位置发生网络故障，导致服务中断；

不支持的灾难场景

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

Primary Cluster 和 Standby Cluster 的角色是相对的：当前为平台提供服务的集群是 Primary Cluster（DNS 指向该集群），而备用集群是 Standby Cluster。故障切换后，这两个角色会互换。

注意事项

此解决方案仅同步 global 集群的 etcd 数据；不包含 registry、chartmuseum 或其他组件的数据；
监控和日志数据也不会同步。请勿将业务集群的监控或日志数据存储在 Primary Cluster 或 Standby Cluster 中：在专用业务集群中安装用于聚合业务集群数据的 VictoriaMetrics Center 和日志存储，并让每个 global 集群仅收集、存储和查询自身的指标和日志。Primary Cluster 中保存的可观测性数据在故障切换后不可用，因此依赖这些数据的 Standby Cluster 将无法观测其刚接管的平台；
为便于故障排查和管理，建议采用类似 standby-global-m1 的节点命名方式，以指示节点所属的集群（Primary 或 Standby）。
不支持集群内应用数据的灾难恢复；
两个集群之间必须具备稳定的网络连接，以确保 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

如果两个集群都设置为使用内置镜像仓库，则必须分别将容器镜像上架到每个集群；
如果 Primary Cluster 部署了 DevOps Eventing v3（knative-operator）及其实例，则必须在 Standby Cluster 中预先部署相同的组件。

流程概述

为平台访问准备统一的域名；
将域名指向 Primary Cluster 的 VIP，并安装 Primary Cluster；
临时将 DNS 解析切换到 Standby Cluster 的 VIP，以安装 Standby Cluster；
将 Primary Cluster 的 ETCD 加密密钥复制到之后将作为 Standby Cluster 控制平面节点的节点；
安装并启用 Global Cluster Disaster Recovery（以前称为 etcd Synchronizer）；
验证同步状态并执行定期检查；
发生故障时，将 DNS 切换到 Standby Cluster，以完成灾难恢复。

所需资源

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

网络要求

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

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

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

TCP 端口	服务	必要原因
`443`	平台 HTTPS	Standby Cluster 使用 Platform Access Address 访问当前活动的平台。 etcd Synchronizer 使用此地址，日志记录和监控组件也会向此地址发送告警回调。
`80`	平台 HTTP	仅当用户通过 HTTP 访问平台时才需要。除此之外，连通性要求与端口 `443` 相同。
`6443`	Kubernetes API 服务器	在安装或重新安装 etcd Synchronizer 期间，Standby Cluster 会连接到活动集群的 API 服务器，以获取同步所需的 etcd CA 材料。
`11443`	内置镜像仓库	Standby Cluster 从通过 Platform Access Address 配置的仓库拉取平台和插件镜像。
`2379`	etcd	Standby Cluster 上的 etcd Synchronizer 从 Primary Cluster 读取 etcd 数据，并将其写入本地 Standby etcd。

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

操作步骤

步骤 1：安装 Primary Cluster

NOTES OF DR (Disaster Recovery Environment) INSTALLING

安装 DR Environment 的 Primary Cluster 时，

首先，记录按照安装 Web UI 指引设置的所有参数。安装 Standby Cluster 时，需要保持某些选项一致。
必须预先配置 User-provisioned Load Balancer，以将发送到虚拟 IP 的流量进行路由。Self-built VIP 选项不可用。
Platform Access Address 字段必须是域名，而 Cluster Endpoint 必须是虚拟 IP 地址。
两个集群都必须配置为使用 An Existing Certificate（必须使用同一个），如有必要，请申请有效证书。Self-signed Certificate 选项不可用。
当 Image Repository 设置为 Platform Deployment 时，Username 和 Password 字段都不能为空；IP/Domain 字段必须设置为用作 Platform Access Address 的域名。
Platform Access Address 的 HTTP Port 和 HTTPS Port 字段都必须为 80 和 443。
进入安装指南的第二个页面（步骤：Advanced）时，Other Platform Access Addresses 字段必须包含当前集群的虚拟 IP。

参考以下文档完成安装：

步骤 2：安装 Standby Cluster

暂时将域名指向 Standby Cluster 的 VIP；

# 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

按照与 Primary Cluster 相同的方式安装 Standby Cluster

NOTES FOR INSTALLING STANDBY CLUSTER

安装 DR Environment 的 Standby Cluster 时，以下选项必须与 Primary Cluster 保持一致：

Platform Access Address 字段。
Certificate 的所有字段。
Image Repository 的所有字段。
重要：确保镜像仓库凭据以及 admin 用户的凭据与 Primary Cluster 上设置的凭据一致。

并确保已按照步骤 1 中的 NOTES OF DR (Disaster Recovery Environment) INSTALLING 执行操作。

参考以下文档完成安装：

步骤 3：启用 etcd 同步

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

INFO
不要求通过负载均衡器进行端口转发。如果 Standby Cluster 可以直接访问活动 global 集群，请通过 Active Global Cluster ETCD Endpoints 指定 etcd 地址。
使用其 VIP 访问 Standby global cluster Web Console，然后切换到 Administrator 视图。
导航到 Marketplace > Cluster Plugins，选择 global 集群。
找到 Global Cluster Disaster Recovery（对于重命名前发布的软件包，其显示名称为 etcd Synchronizer），单击 Install，并配置以下参数：
4.3.1+
4.3.0
前提条件（仅适用于 4.3.1+）：在 Standby global cluster 上创建 etcd-sync-active-cluster-token Secret。首先，从活动 global cluster 获取用于访问活动 global cluster API 服务器的 bearer token。然后复制命令输出，并在创建 Secret 时使用该输出。Secret 会将令牌存储在数据键 token 下。
# Run this command on the active cluster. kubectl -n cpaas-system get secret k8sadmin -o jsonpath='{.data.token}' | base64 -d
复制输出值，然后在 Standby Cluster 上运行以下命令：
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 cluster 的 VIP。

如果未通过负载均衡器转发端口 2379，请正确配置 Active Global Cluster ETCD Endpoints。

将 Standby Cluster ETCD Endpoints 设置为 Standby Cluster 的 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 后，插件安装才会继续。
验证引导 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}' 返回非空值后再继续。

验证 Standby Cluster 上的同步 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：键存在于 Primary global cluster 中，但在 Standby 中缺失。这通常会在重启当前 etcd-sync leader Pod 后解决。
LOCAL ETCD surplus keys：键存在于 Standby global cluster 中，但不在 Primary 中。请与运维团队确认后再删除这些键。

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

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)'

灾难恢复流程

卸载 Alauda Container Platform etcd Synchronizer 前，验证主备一致性

此操作将卸载 Global Cluster Disaster Recovery（之前称为 etcd Synchronizer）。卸载前，请确认备用集群中的数据与主集群一致。如果备用集群缺少主集群中存在的数据，此时卸载插件可能导致所有者引用解析错误，并可能删除业务集群节点 Machine 对象——包括不可变操作系统集群，此类集群的底层虚拟机也会因此被删除。如果一致性检查报告存在缺失键或多余键，请勿卸载插件；请先解决不一致问题或联系技术支持。

如有必要，重启备用集群上的 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

验证备用集群中的数据一致性（检查方式与步骤 3相同）。如果检查报告存在缺失键或多余键，则备用集群与主集群不一致：请勿继续下一步。请先解决不一致问题或联系技术支持。在两个集群上，还要确认没有处于非运行状态的 Machine 节点，并在继续操作前解决相关问题：
kubectl get machines.platform.tkestack.io
卸载 Global Cluster Disaster Recovery（对于重命名前发布的软件包，该组件显示为 etcd Synchronizer）；
移除两个 VIP 上针对 2379 的端口转发；
将平台域名 DNS 切换到备用 VIP，该 VIP 现在将成为主集群；

验证 DNS 解析：

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

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

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

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

如果业务集群将监控数据发送到主集群，请在业务集群中重启 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

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

上架软件包

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

#Global 集群灾难恢复

#目录

#概述

#支持的灾难场景

#不支持的灾难场景

#注意事项

#流程概述

#所需资源

#网络要求

#操作步骤

#步骤 1：安装 Primary Cluster

#步骤 2：安装 Standby Cluster

#步骤 3：启用 etcd 同步

#灾难恢复流程

#例行检查

#上架软件包