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

本文分享自华为云社区《Karmada v1.15 版本发布！多模板工作负载资源感知能力增强》，作者：云容器大未来。 Karmada 是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 Kubernetes 原生 API 的能力，Karmada可以平滑迁移单集群工作负载，并且仍可保持与 Kubernetes 周边生态工具链协同。 Karmada v1.15版本现已发布，本版本包含下列新增特性： ● 多模板工作负载的资源精确感知 ● 集群级故障迁移功能增强 ● 结构化日志 ● Karmada 控制器和调度器性能显著提升 新特性概览 多模板工作负载的资源精确感知 Karmada 利用资源解释器获取工作负载的副本数和资源请求，并据此计算工作负载所需资源总量，从而实现资源感知调度，联邦配额管理等高阶能力。这种机制在传统的单模板工作负载中表现良好。然而，许多AI大数据应用的工作负载 CRD（如 FlinkDeployments，PyTorchJob 和 RayJob 等）包含多个 Pod 模板或组件，每个组件都有独特的资源需求。由于资源解释器仅能处理单个模板的资源请求，无法准确反映不同模板间的差异，导致多模板工作负载的资源计算不够精确。 在这个版本中，Karmada 强化了对多模板工作负载的资源感知能力，通过扩展资源解释器，Karmada 现在可以获取同一工作负载不同模板的副本数和资源请求，确保数据的精确性。这一改进也为多模板工作负载的联邦配额管理提供了更加可靠和精细的数据支持。 假设你部署了一个 FlinkDeployment，其资源相关配置如下： spec: jobManager: replicas: 1 resource: cpu: 1 memory: 1024m taskManager: replicas: 1 resource: cpu: 2 memory: 2048m 通过 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 致力于对其提供更强有力的支持。在接下来的版本中，我们将基于此功能进一步加强对多模板工作负载的调度支持，提供更加细粒度的资源感知调度——敬请期待更多更新！ 更多有关此功能的资料请参考：多 Pod 模板支持。 集群级故障迁移功能增强 在之前的版本中，Karmada 提供了基本的集群级故障迁移能力，能够通过自定义的故障条件触发集群级别的应用迁移。为了满足有状态应用在集群故障迁移过程中保留其运行状态的需求，Karmada 在 v1.15 版本支持了集群故障迁移的应用状态中继机制。对于大数据处理应用（例如 Flink），利用此能力可以从故障前的 checkpoint 重新启动，无缝恢复到重启前的数据处理状态，从而避免数据重复处理。 社区在 PropagationPolicy/ClusterPropagationPolicy API 中的 .spec.failover.cluster 下引入了一个新的 StatePreservation 字段， 用于定义有状态应用在故障迁移期间保留和恢复状态数据的策略。结合此策略，当应用从一个故障集群迁移到另一个集群时，能够从原始资源配置中提取关键数据。