Karmada更高效地实现故障转移

随着云原生技术的发展，其应用场景不断扩大。越来越多的企业开始将应用程序部署在 Kubernetes 集群中，随着 Kubernetes 集群规模的不断扩大，也带来了许多管理挑战，例如多集群间负载均衡、资源调度、故障转移等问题。为了解决这些问题，Karmada 多集群管理平台应运而生，同时还提供了强大的故障转移能力。

在多云多集群场景中，为了提高业务的高可用性，工作负载可能会被部署在多个不同的集群。在 Karmada 中，当集群发生故障，或是用户不希望在某个集群上继续运行工作负载时，集群状态将被标记为不可用，并被添加上一些污点。Taint-manager 检测到集群故障之后，会从这些故障集群中驱逐工作负载，被驱逐的工作负载将被调度至其他最适合的集群，从而达成故障迁移的目的，保证了用户业务的可用性与连续性。

一、故障迁移的场景

为何需要故障转移？下面来介绍一些多集群故障迁移的场景：

管理员在 Karmada 控制面部署了一个离线业务，并将业务 Pod 实例分发到了多个集群。突然某个集群发生故障，管理员希望 Karmada 能够把故障集群上的 Pod 实例迁移到其他条件适合的集群中；
普通用户通过 Karmada 控制面在某一个集群上部署了一个在线业务，业务包括服务器实例、配置文件等，服务通过控制面上的 ELB 对外暴露，此时某一集群发生故障，用户希望把整个业务能迁移到另一个情况较适合的集群上，业务迁移期间需要保证服务不断服；
管理员将某个集群进行升级，作为基础设施的容器网络、存储等发生了改变，管理员希望在集群升级之前把当前集群上的应用迁移到其他适合的集群中去，业务迁移期间需要保证服务不断服。

二、如何进行故障迁移

上图展示了两种不同的迁移方式

Karmada 支持用户设置分发策略，在集群发生故障后，将故障集群实例进行自动的集中式或分散式的迁移。如图用户在 Karmada 中加入了三个集群，分别为：member1、member2 和 member3。

在 Karmada 的控制面部署了一个副本数为 3 的工作负载，并通过部署策略（PropagationPolicy）将其分发到了集群 member1 和 member2 上。
当集群 member1发生故障之后，其工作负载上的 Pod 实例将会被驱逐，通过 PropagationPolicy/ClusterPropagationPolicy 的副本调度策略 ReplicaSchedulingStrategy 来控制 Pod 被全部迁移到集群 member2 或是分散迁移至两个集群中。

三、工作负载被驱逐的时间线

下面通过示例，简单讲解在 DCE 5.0 多云编排模块中，一个工作负载被驱逐的时间线：

首先，每一段时间调用一次集群的 API 用以记录集群的健康状态，当集群状态始终为健康时，我们认定集群的健康状态正常。此时我们将 DCE 与集群 APIserver 之间的 TCP 断开，10s-20s 之内，若没有获取到集群的健康状态将认为集群异常，被标记为非健康状态，同时打上 NoSchedule 的污点，如果集群的不健康状态持续一段时间，在指定时间内若集群仍然没有恢复健康，超过指定的驱逐容忍时长后，将被打上 NoExecute 的污点，最终被驱逐。