应用故障迁移

在多集群场景下，用户的工作负载可能会部署在多个集群中，以提高服务的高可用性。当检测到集群故障时，Karmada 已经支持应用在多集群的故障转移。 这是从集群的视角出发的。但是，有些集群的故障只会影响特定的应用，如果从集群的角度来看，我们需要区分受影响和未受影响的应用程序。 此外，当集群的控制平面处于健康状态时，应用程序可能仍然处于不可用的状态。因此，Karmada 需要从应用的角度提供一种故障迁移的手段。

为什么需要应用级故障迁移

以下介绍一些应用级故障转移的场景:

  • 管理员通过抢占式调度在多个集群中部署应用程序。当集群资源紧缺时，原本正常运行的低优先级应用被抢占，长时间无法正常运行。此时，应用程序无法在单集群内进行自我修复。用户希望尝试将其调度到另一个集群，以确保持续提供服务。
  • 管理员使用云供应商的竞价实例来部署无状态的计算任务。用户使用竞价型实例部署应用时，可能会因为资源被回收而导致应用运行失败。 在这种情况下，调度器感知到的资源量是资源配额的大小，而不是实际可用的资源。这时候，用户希望将之前失败的应用调度到另一个可用的集群。
  • ….

如何启用该功能

当应用程序从一个集群迁移到另一个集群时，应用需要确保它的依赖项同步迁移。 因此，您需要确保启用了 PropagateDeps 特性开关并且在PropagationPolicy中设置了 propagateDeps: true。自 Karmada v1.4 以来，PropagateDeps 特性开关已经处于 Beta 阶段，并且默认启用。

另外，应用是否需要迁移取决于应用的健康状态。Karmada 的“资源解释器框架”是为解释资源结构而设计的，它为用户提供解释器操作来告诉 Karmada 如何确定特定对象的健康状态。如何解析资源的健康状态由用户决定。在使用应用的故障迁移之前，您需要确保已配置应用程序的 interpretHealth 规则。

应用故障迁移受 Failover 特性开关控制。自 Karmada v1.4 以来，Failover 特性开关已经处于 Beta 阶段，并且默认启用。 此外，如果您使用优雅驱逐的清除模式，则需要启用 GracefulEviction 特性开关。自 Karmada v1.4 以来，GracefulEviction 特性开关也已处于 Beta 阶段，并且默认启用。

配置应用故障迁移

PropagationPolicy的 .spec.failover.application 字段可以来表示应用故障迁移的规则。

它有以下字段可以设置:

  • DecisionConditions
  • PurgeMode
  • GracePeriodSeconds

配置决定条件

DecisionConditions 代表执行故障迁移的决定条件。只有当其中的所有条件都满足了应用的故障迁移才会执行。 目前，它包括对应用不健康状态的容忍时间，默认为300s。

PropagationPolicy可以配置如下:

  1. apiVersion: policy.karmada.io/v1alpha1
  2. kind: PropagationPolicy
  3. metadata:
  4.   name: test-propagation
  5. spec:
  6.   #...
  7.   failover:
  8.     application:
  9.       decisionConditions:
  10.         tolerationSeconds: 300
  11.       #...

配置驱逐模式

PurgeMode 代表如何从一个故障的集群迁移到另一个集群的方式。 Karmada 支持三种不同的驱逐模式:

  • Immediately 表示 Karmada 将立即驱逐遗留的应用。
  • Graciously 表示 Karmada 将等待应用在新集群上恢复健康，或者在达到超时后才驱逐应用。 你同时需要配置 GracePeriodSeconds。如果新集群上的应用无法达到 Healthy 状态，Karmada 将在达到 GracePeriodSeconds 后删除该应用。默认为 600 秒。
  • Never 表示 Karmada 不会驱逐应用，用户手动确认如何清理冗余副本。

PropagationPolicy 可以配置为如下:

  1. apiVersion: policy.karmada.io/v1alpha1
  2. kind: PropagationPolicy
  3. metadata:
  4.   name: test-propagation
  5. spec:
  6.   #...
  7.   failover:
  8.     application:
  9.       decisionConditions:
  10.         tolerationSeconds: 300
  11.       gracePeriodSeconds: 600
  12.       purgeMode: Graciously
  13.       #...

或者

  1. apiVersion: policy.karmada.io/v1alpha1
  2. kind: PropagationPolicy
  3. metadata:
  4.   name: test-propagation
  5. spec:
  6.   #...
  7.   failover:
  8.     application:
  9.       decisionConditions:
  10.         tolerationSeconds: 300
  11.       purgeMode: Never
  12.       #...

示例

假设你已经配置了一个 propagationPolicy:

  1. apiVersion: policy.karmada.io/v1alpha1
  2. kind: PropagationPolicy
  3. metadata:
  4.   name: nginx-propagation
  5. spec:
  6.   failover:
  7.     application:
  8.       decisionConditions:
  9.         tolerationSeconds: 120
  10.       purgeMode: Never
  11.   resourceSelectors:
  12.     - apiVersion: apps/v1
  13.       kind: Deployment
  14.       name: nginx
  15.   placement:
  16.     clusterAffinity:
  17.       clusterNames:
  18.         - member1
  19.         - member2
  20.         - member3
  21.     spreadConstraints:
  22.       - maxGroups: 1
  23.         minGroups: 1
  24.         spreadByField: cluster
  25. ---
  26. apiVersion: apps/v1
  27. kind: Deployment
  28. metadata:
  29.   name: nginx
  30.   labels:
  31.     app: nginx
  32. spec:
  33.   replicas: 2
  34.   selector:
  35.     matchLabels:
  36.       app: nginx
  37.   template:
  38.     metadata:
  39.       labels:
  40.         app: nginx
  41.     spec:
  42.       containers:
  43.         - image: nginx
  44.           name: nginx

现在应用被调度到 member2 中，这两个副本正常运行。 此时给 member2 中的所有节点标记为不可调度并驱逐所有副本以构建应用的异常状态。

  1. # mark node "member2-control-plane" as unschedulable in cluster member2
  2. $ kubectl --context member2 cordon member2-control-plane
  3. # delete the pod in cluster member2
  4. $ kubectl --context member2 delete pod -l app=nginx

你可以立即从 ResourceBinding 中发现应用变成不健康的状态。

  1. #...
  2. status:
  3.   aggregatedStatus:
  4.     - applied: true
  5.       clusterName: member2
  6.       health: Unhealthy
  7.       status:
  8.         availableReplicas: 0
  9.         readyReplicas: 0 
  10.         replicas: 2

达到 tolerationSeconds 后，会发现 member2 中的 deployment 已经被驱逐，重新调度到 member1 中。

  1. #...
  2. spec:
  3.   clusters:
  4.     - name: member1
  5.       replicas: 2
  6.   gracefulEvictionTasks:
  7.     - creationTimestamp: "2023-05-08T09:29:02Z"
  8.       fromCluster: member2
  9.       producer: resource-binding-application-failover-controller
  10.       reason: ApplicationFailure
  11.       suppressDeletion: true

您可以在 gracefulEvictionTasks 中将 suppressDeletion 修改为 false，确认故障后驱逐故障集群中的应用。

应用故障迁移 - 图1备注

应用故障转移的开发仍在进行中。我们正在收集用户案例。如果您对此功能感兴趣，请随时开启一个 enhancement issue 让我们知道。