Karmada v1.15 版本发布！多模板工作负载资源感知能力增强

● 多模板工作负载的资源精确感知

● 集群级故障迁移功能增强 

● 结构化日志

● Karmada 控制器和调度器性能显著提升

在这个版本中，Karmada 强化了对多模板工作负载的资源感知能力，通过扩展资源解释器，Karmada 现在可以获取同一工作负载不同模板的副本数和资源请求，确保数据的精确性。这一改进也为多模板工作负载的联邦配额管理提供了更加可靠和精细的数据支持。

通过 ResourceBinding，你可以查看资源解释器解析出的 FlinkDeployment 各个模板的副本数以及资源请求。

spec:
  components:
  - name: jobmanager
    replicaRequirements:
      resourceRequest:
        cpu: "1"
        memory: "1.024"
    replicas: 1
  - name: taskmanager
    replicaRequirements:
      resourceRequest:
        cpu: "2"
        memory: "2.048"
    replicas: 1

此时，FederatedResourceQuota 计算的 FlinkDeployment 占用的资源量为：

status:
    overallUsed:
      cpu: "3"
      memory: 3072m

注意：该特性​​目前处于 Alpha 阶段，需要启用 MultiplePodTemplatesScheduling 特性开关​​才能使用。

随着多模板工作负载在云原生环境中的广泛应用，Karmada 致力于对其提供更强有力的支持。在接下来的版本中，我们将基于此功能进一步加强对多模板工作负载的调度支持，提供更加细粒度的资源感知调度——敬请期待更多更新！

社区在 PropagationPolicy/ClusterPropagationPolicy API 中的 .spec.failover.cluster 下引入了一个新的 StatePreservation 字段， 用于定义有状态应用在故障迁移期间保留和恢复状态数据的策略。结合此策略，当应用从一个故障集群迁移到另一个集群时，能够从原始资源配置中提取关键数据。

以 Flink 应用为例，在 Flink 应用中，jobID 是一个唯一的标识符，用于区分和管理不同的 Flink 作业（jobs）。当集群发生故障时，Flink 应用可以利用 jobID 来恢复故障前作业的状态，从故障点处继续执行。具体的配置和步骤如下：

apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: foo
spec:
  #...
  failover:
    cluster:
      purgeMode: Directly
      statePreservation:
        rules:
          - aliasLabelName: application.karmada.io/cluster-failover-jobid
            jsonPath: "{ .jobStatus.jobID }"

功能约束：

Karmada 在 1.15 版本引入了结构化日志支持，可通过 –logging-format=json 启动参数配置 JSON 格式输出。结构化日志示例如下：

{
  "ts":“日志时间戳”,
  "logger":"cluster_status_controller",
  "level": "info",
  "msg":"Syncing cluster status",
  "clusterName":"member1"
}

结构化日志的引入显著提升了日志的可用性与可观测性：

● 高效集成：可无缝对接 Elastic、Loki、Splunk 等主流日志系统，无需依赖复杂的正则表达式或日志解析器。

● 高效查询：结构化字段支持快速检索与分析，显著提升故障排查效率。

● 可观察性增强：关键上下文信息（如集群名、日志级别）以结构化字段呈现，便于跨组件、跨时间关联事件，实现精准问题定位。

● 可维护性提升：结构化日志使开发者和运维人员在系统演进过程中更易于维护、解析和调整日志格式，保障日志体系的长期稳定与一致性。

控制器方面，通过引入优先级队列，控制器能够在重启或切主后优先响应用户触发的资源变更，从而显著缩短服务重启和故障切换过程中的停机时间。

注意：该特性​​目前处于 Alpha 阶段，需要启用 ControllerPriorityQueue 特性开关才能使用。

测试记录了在开启精确调度组件 karmada-scheduler-estimator 情况下，调度 5,000 个 ResourceBinding 所用的时间，结果如下：

● 调度器吞吐量 QPS 从约 15 提升至约 22，性能提升达 46%；

● gRPC 请求次数从约 10,000 次减少至约 5,000 次，降幅达 50%。

这些测试证明，在 1.15 版本中，Karmada 控制器和调度器的性能得到了极大提升。未来，我们将继续对控制器和调度器进行系统性的性能优化。

贡献者列表：