Karmada 是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 Kubernetes 原生 API 的能力，Karmada 可以平滑迁移单集群工作负载，并且仍可保持与 Kubernetes 周边生态工具链协同。

在最新发布的 v1.7 版本中，Karmada 新增了应用跨集群定时弹性伸缩的能力，用户可以通过Cron 表达式设定一个时间计划，Karmada 根据设定的时间对应用进行扩缩容，既可以定时直接调整工作负载的副本实例数，又可以结合FederatedHPA 策略定时调整 FederatedHPA 伸缩范围，实现复杂场景下的工作负载伸缩。

本版本其他新增特性：

• 引入了MultiClusterService API，提供多集群场景下南北向、东西向服务发现能力。
  

• 提供了批量迁移单集群资源能力，运行在单集群的应用可以批量迁移至 Karmada并且无需中止或重启容器。

• 引入了基于优先级的资源抢占特性，PropagationPolicy/ClusterPropagationPolicy 现在可以通过声明抢占行为，按照优先级从另一个PropagationPolicy/ClusterPropagationPolicy抢占资源，从而实现定制的部署策略。

• 增强了FederatedHPA能力，除了支持CPU 和Memory之外，FederatedHPA 现在还可以根据自定义指标弹性伸缩。

新特性概览

CronFederatedHPA

企业应用不仅有日常的业务负载波动，还会有周期性的突发流量洪峰业务。此种情况下，用户既期望能根据指标弹性伸缩应对日常业务负载波动，又期望能定时弹性伸缩应对特定时间的流量洪峰。

最新发布的 v1.7 版本带来了定时弹性伸缩（CronFederatedHPA）特性，实现在固定时间进行跨集群的扩缩容，并且可以和 FederatedHPA 策略共同作用，定时调整 FederatedHPA 伸缩范围，实现复杂场景下的跨集群工作负载弹性伸缩。

从图中还可以看出，CronFederatedHPA 有两种工作模式，一种模式是直接伸缩具有 scale 子资源的工作负载（如 Deployment 和StatefulSet），进而调整工作负载在成员集群中的副本实例数；另一种模式是伸缩 FederatedHPA，调整其最大/最小实例数，间接调整工作负载实例数。

当使用CronFederatedHPA伸缩工作负载时，Karmada 将定期检查配置时间，如果时间到达，则伸缩对应工作负载，伸缩的工作负载将被 Karmada 调度器根据配置和集群资源实时状态，调度到多个集群，实现定时跨集群弹性伸缩，配置示例如下：

apiVersion: autoscaling.karmada.io/v1alpha1  
kind: CronFederatedHPA  
metadata:  
  name: nginx-cronfhpa  
spec:  
  scaleTargetRef:   
    apiVersion: apps/v1  
    kind: Deployment  
    name: nginx  
  rules:  
  - name: "scale-up"  
    schedule: "0 9 * * *"  
    targetReplicas: 50  
  - name: "scale-down"  
    schedule: "0 10 * * *"  
    targetReplicas: 1

如上配置，将会在每天早上9点，将 nginx 负载实例数扩容为50，早上10点将实例数缩容为1。

当使用CronFederatedHPA伸缩FederatedHPA 时，Karmada 将定期检查配置时间，如果时间到达，则伸缩对应 FederatedHPA 的最大/最下值，从而伸缩工作负载，伸缩的工作负载同样会被 Karmada 调度器根据配置和集群资源实时状态，调度到多个集群，实现定时跨集群弹性伸缩，配置示例如下：

apiVersion: autoscaling.karmada.io/v1alpha1
kind: CronFederatedHPA
metadata:
  name: nginx-cronfhpa
spec:
  scaleTargetRef:
    apiVersion: autoscaling.karmada.io/v1alpha1
    kind: FederatedHPA
    name: nginx-fhpa
  rules:
  - name: "scale-up"
    schedule: "0 9 * * *"
    targetMinReplicas: 50
  - name: "scale-down"
    schedule: "0 10 * * *"
    targetMinReplicas: 1

如上配置，将会在每天早上9点，将nginx-hpa的最小值设置50，早上10点将最小值设置为1，从而在保留根据其负载指标来伸缩工作负载规模的同时，间接定时伸缩工作负载。

注意，应确保 CronFederatedHPA 执行的伸缩操作不会与任何其他正在进行的伸缩操作冲突。换句话说，如果工作负载已经由 FederatedHPA管理，您不应再叠加 CronFederatedHPA 直接伸缩工作负载，否则会出现不确定的结果。

https://karmada.io/docs/userguide/autoscaling/cronfederatedhpa

MultiClusterService

在之前的版本中，Karmada 提供了多集群服务（MCS）发现能力，新引入的MultiClusterService 一方面可以简化服务发现配置，另一方面可以提供向统一的负载均衡器注册服务能力。

用户在使用 MCS功能时，需要创建多个资源，例如 ServiceExport、ServiceImport、PropagationPolicy 等，如此多资源的创建对于用户来说是不够友好的。现在，用户可以通过创建 MultiClusterService资源对象来统一定义跨集群服务发现行为，相较于之前的实现，方便很多。这部分功能社区正在实现中，预计在 1.8 版本会包含该功能。

用户可以通过创建以下 MultiClusterService对象来进行跨集群服务发现：

apiVersion: networking.karmada.io/v1alpha1
kind: MultiClusterService
metadata:
  name: foo
spec:
  types:
  - CrossCluster
  range:
    clusterNames:
    - member2

MCS 功能是根据 Kubernetes 社区 sig-multicluster 提出的 mcs-api 实现的，但是它并没有解决多集群服务暴露的问题，因此我们提出了 MultiClusterService 这个新的 API，用于在 OSI 第4层上暴露多集群服务。MultiClusterService 能将外部流量转发到由 Karmada 管理的成员集群服务后端，突破单一服务边界限制，并实现来自多个集群流量统一入口。

用户可以通过创建以下 MultiClusterService 对象来保留多集群服务：

apiVersion: networking.karmada.io/v1alpha1
kind: MultiClusterService
metadata:
  name: foo
spec:
   ports:
   - port: 80
   types:
   - LoadBalancer

1. 用户创建Deployment 和 Service，并将它们分发到成员集群中；

2. 用户创建 multiClusterService 资源；

3. Karmada通过multicluster-cloud-provider-xxx（xxx为某一云服务提供商，该组件为其具体的实现）注册 pod IP 地址到 LB 实例；

4. 用户通过 4层 访问 LB 实例。

批量迁移

Karmada 作为多云多集群管理系统，非常关注用户从单集群扩展为多集群的迁移体验，尤其是用户原有的单集群中已经部署了很多资源，我们希望用户已部署的资源能够平滑地迁移到 Karmada。因此，本版本增强了 Karmada 的资源迁移能力，支持用户批量迁移原集群的现有资源到 Karmada，并且迁移过程中已存在的Pod 不受影响，即相关容器不会重启。

现在使用 Karmada 接管单集群应用，可以借助 PropagationPolicy或 ClusterPropagationPolicy 批量选择应用，并指定冲突解决策略（.spec.conflictResolution: Overwrite）即可保证平滑迁移，不会中断应用运行。

如上图所示，用户执行批量迁移只需按如下步骤进行：

步骤一：原集群由 Karmada 接管后，资源配置只需应用到 Karmada 控制面，不再需要应用到原集群。

步骤二：将所有资源的YAML配置应用到Karmada控制面, 作为Karmada的 ResourceTemplate。

步骤三：编写 PropagationPolicy, 并将其应用到 Karmada 控制面。您需要注意以下两个字段：

• spec.conflictResolution: Overwrite：该字段的值应配置成 Overwrite。

• spec.resourceSelectors：指定需要批量迁移的资源。

步骤四：余下的迁移操作将由 Karmada 自动完成。

下面给出一个示例，假设用户希望把指定 namespace 的所有 Deployment 从 member1 集群迁移到 Karmada，用户需要应用以下 PropagationPolicy配置：

apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: deployments-pp
  namespace: foo
spec:
  conflictResolution: Overwrite
  placement:
    clusterAffinity:
      clusterNames:
      - member1
priority: 0
resourceSelectors:
- apiVersion: apps/v1
  kind: Deployment
  namespace: foo
schedulerName: default-scheduler

关于批量迁移的更多信息，请参考：

https://karmada.io/docs/administrator/migration/migrate-in-batch

https://karmada.io/docs/tutorials/resource-migration

基于优先级的资源抢占

在先前的版本中，PropagationPolicy/ClusterPropagationPolicy (下文简称 Policy ) 已有优先级的概念，如果工作负载与多个Policy 相匹配，Karmada 将选择优先级最高的一个。但优先级仅在资源模板第一次匹配时生效。一旦资源模板被某个 Policy 选中，后续的 Policy 即使具有更高的优先级也不能抢占它。

然而，用户在配置Policy 时通常很难预见未来的扩展场景，他们通常会优先配置一个通用宽泛的Policy。当具体应用程序需要特殊配置时，用户希望提供个性化的 Policy来接管该应用程序，也就是说用户希望高优先级的Policy能够抢占低优先级的 Policy。

因此，Karmada针对这类场景，引入了Policy抢占特性。该特性由特性开关 PropagationPolicyPreemption控制，特性开启后，即使工作负载已通过 Policy 分发，它们也可能被更高优先级的 Policy 抢占。

我们不妨继续以上一节中批量迁移的 Policy 举例，假设用户已经通过该示例中的 Policy 将成员集群所有的 Deployment 迁移到 Karmada，但用户希望针对其中的 nginx Deployment 应用更高优先级的 Policy 进而将其扩展到 member2 集群，则用户需要确认以下三个要求是满足的：

1. 确认karmada-controller-manager已开启 PropagationPolicyPreemption特性开关，即其启动参数包含 --feature-gates=PropagationPolicyPreemption=true

2. 新的 Policy 的 priority 字段的值更大

3. 新的 Policy 的 preemption 字段的值应配置为 Always
   

apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: nginx-pp
spec:
  conflictResolution: Overwrite
  placement:
    clusterAffinity:
      clusterNames:
      - member1
      - member2 ## propagate to more clusters in addition to member1
  priority: 10 ## priority greater than above PropagationPolicy (10 > 0)
  preemption: Always ## preemption should be Always
  resourceSelectors:
  - apiVersion: apps/v1
    kind: Deployment
    name: nginx-deploy

关于 Policy 抢占的更多信息，请参考：

使用自定义指标弹性伸缩

FederatedHPA不仅支持CPU和内存等资源指标，最新的 v1.7 版本还支持了通过自定义指标弹性伸缩。启用该能力需要安装karmada-metrics-adapter组件，其具体工作方式为：

1. FederatedHPA控制器通过使用标签选择器定期查询指标数据。

2. karmada-apiserver 收到指标查询，会路由到之前通过API 服务注册的karmada-metrics-adapter。

3. karmada-metrics-adapter 一直在监控集群的 Pod，当请求发来时，它会查询目标集群(Pod所在的集群)的指标数据。收集指标后，karmada-metrics-adapter将整合数据并将数据返回。

4. FederatedHPA 控制器会根据指标数据计算所需要的副本，并直接扩展工作负载。

https://karmada.io/docs/tutorials/autoscaling-with-custom-metrics/

版本升级

Karmada v1.7 版本 API 兼容 v1.6 版本 API，v1.6 版本的用户仍然可以平滑升级到 v1.7 版本。

致谢贡献者

Karmada v1.7 版本包含了来自42位贡献者的184次代码提交，在此对各位贡献者表示由衷的感谢：

贡献者GitHub ID:

参考链接

Release Notes：https://github.com/karmada-io/karmada/releases/tag/v1.7.0

CronFederatedHPA：https://karmada.io/docs/userguide/autoscaling/cronfederatedhpa

MultiClusterService：https://karmada.io/docs/tutorials/autoscaling-with-custom-metrics

批量迁移：https://karmada.io/docs/administrator/migration/migrate-in-batch

Policy抢占设计文档：https://github.com/karmada-io/karmada/tree/master/docs/proposals/scheduling/policy-preemption

使用自定义指标弹性伸缩：https://karmada.io/docs/tutorials/autoscaling-with-custom-metrics

Karmada 1.7升级文档：https://karmada.io/docs/administrator/upgrading/v1.6-v1.7

附：Karmada社区交流地址

Karmada官网：https://karmada.io/

项目地址：https://github.com/karmada-io/karmada

Slack地址：https://slack.cncf.io/